Because the glsl front-end uses Ruamoko to compile its builtins, it
needs to switch languages, and the cleanest way to do so is to use a
context object that gets passed around. This removes not only the
current_language global, but also (as a bonus) any real references to
flex's scanner object (there's still a pointer in rua_ctx_t, but it's no
longer a parameter (which caused some pain in the change)).
While it is a pessimism, I really want to get rid of fold_constants (in
favor of something smarter), and it's currently in the way of more
important things.
The main goal was to make it possible to give generic functions
definitions (since the code would be very dependent on the actual
parameter types), but will also allow for inline functions. It also
helped move a lot of the back-end dependent code out of semantics
processing and almost completely (if not completely) out of the parser.
Possibly more importantly, it gets the dags flushing out of the parser,
which means such is now shared by all front-ends.
There's probably a lot of dead code in expr.c now, but that can be taken
care of another time.
When getting an offset alias of an already aliased def, the offset needs
to be updated so it points to the correct part of the def. This is
actually a rather old bug but it got uncovered somehow with my rework of
the ruamoko semantic processing (probably an altered cast).
I guess I'd wanted to avoid supporting automatic types in type
functions, but that broke long and unsigned int: either no type, or just
int, depending on the decl style.
Unfortunately, it turns out that generic functions are over-grouped so
all functions with the same name get the last definition, so `mix` with
a float (which should get GLSLstd450FMix) gets the bool version instead
(SpvOpSelect).
When the number of supplied vectors matches the number of columns in the
matrix and all vectors have the same width as the number of rows in the
matrix, there's no need to expand the vectors into components only to be
gathered again.
SPIR-V requires that matrices are constructed from vectors rather than
individual components. While not optimal, iqm.vert's output now passes
spirv-val. Also probably still lots wrong with fine details.
I think I need to come up with a better way of defining glsl builtins
and the strings are rather ugly (and I don't want to use qfcc system
header files).
iqm.vert now compiles, but doesn't pass validation yet (matrix bugs).
And, nicely, simplify it quite a bit. I'm not sure why I didn't thinkg
of this approach before. While the ruamoko back-end doesn't support
matrices yet, the expressions are handled.
As a side effect, type checking on comparisons is "stricter" in that
more potentially bogus comparisons (eg, int-float) are caught, resulting
in a few warnings in ruamoko code and even finding a couple of bugs.
Using bit masks for valid source types for each destination type makes
the logic a lot easier to read. Still had to have some explicit checks
for enums and bools.
The code gen return statements checks for out/inout parameters in the
current function and thus could result in some undesired behavior when
constants are evaluated within such a function.
I found a need to check for shifts separately (not sure it's the right
approach for that problem, though), and there are a few more math ops
than just +-*/.
I'm not sure what it's useful for, but GLSL has a function for it thus I
decided to add the instruction to the VM, so this is part of the
compiler side.
The tricky bit was figuring out how to get `floor()` out of the
available instructions. It's handy that the comparison ops always
returned floats and didn't force the use of branches.
Now both width and columns must match for an instruction to be selected.
Found a few errors in my opcode specs, and some minor goofs in the type
system (really just overthinking things when I added matrices).
Implemented via specific overloads of the function.
It's not quite working correctly in that parameter names are taken from
the declaration instead of definition. However, this seems to be an old
bug that went unnoticed due to me almost always using the same parameter
names in declaration and definition.
Also, the code in get_function() is a horrible mess.
However, the basic idea turned out to be simpler than I though (though
details of the implementation are indeed a little trickier): generic
functions are essentially prototype generators when implemented using
non-generic specialized overloads.
Yet another step closer to glsl support.
While it wasn't correct anyway (neither vectors nor quaternions are
colors), the additional names broke q.s in the quaternion.r test, likely
due to there being two s fields.
For now, it's just recording that type type has attributes (encoding
begins with %) and resurrecting types_same which is used only when
matching with types with attributes, so there's still a fair bit of work
to do.
I'm not sure why I made those functions take const type_t *, but they
didn't need it. There's still a relevant fixime in find_handle, but I
haven't decided how to fix that one just yet.
I'm sure there are still some warts, but interface declaration now works
for spir-v and a real vertex shader can be compiled (albeit one that
doesn't use matrices).
Arrays done via the field code since they use the same opcode and logic.
For now swizzles are just swizzles and don't support zeroing or negating
(but doing one or the other (not both) should be easy).
This was a nasty one to find as it was the unary expression rewrite that
triggered the bug (by causing tighter if tests to be generated, which
surprised me: I wasn't even trying for better if tests). I'm actually
not sure why things worked at all, but this fixes the crashes and other
weird behavior resulting from calls to performSelector.
Two tests are included because I found a separate bug (not fixed yet,
tested by calluse2) while getting the calluse test working.
It returns the number of elements in a type (so something like `countof`
(hopefully that's what the up-coming C feature will be called) can be
implemented), but it applies to structs, vectors, etc (eg, 9 for mat3).
Explicitly typed compound initializers are what C uses and allows them
to initialized `auto` vars and even pass through `...`. Not tested yet
other than ensuring existing tests didn't break.
While storing the scope in a block was the right idea, the
implementation wasn't quite right as it resulted in the current scope
getting set at the wrong times resulting in incorrect symbol access when
shadowing was in effect.
I guess that was a mental FIXME for later, but later came sooner. The
declaration doesn't seem to be working properly, but I'll worry about
that later when I can get some automated tests going.
I'm not sure whether I'll stick with the current encoding, but it turns
out it's necessary to separate function types on parameter qualifiers (I
was half expecting that, though).
Because spir-v's bools are abstract and have no specific size, bool and
lbool need to both have the same spir-v id, as do the vector
counterparts, so when one gets emitted, the id is copied to the mirror
type.
Since spir-v needs actual bools for its conditional instructions, the
time to do bool properly finally came. As expected, the changes caused
quite a mess, but Ruamoko now does bool/true/false.
The tags might have other uses thus the generic term, but this allows
spir-v variables to be declared with the correct pointer storage
classes. Now spirv-val is complaining about my interfaces, so progress :)
Non-const params use references and so need somewhere to store the
arguments. Local variables could be passed directly (parameters normally
require function storage class, which local variables are), but that's a
potential optimization for later.
This required adding a `var` symbol type. For now, it holds just the
storage class, but it might be good for the initializer, too.
Also, clean up some pointer/reference inconsistencies.
As I suspected, the dereference was premature, although it can act as an
optimization when multiple fields of an object are accessed, though it
won't work for writes to lvalues (which means my fixes for spir-v
code-gen currently don't work for lvalue writes). Still, progress. Need
to get field member ids set.
It turns out my field access processing works well enough for vectors.
I'm not sure about pointer access as I may have done the pointer
dereference prematurely.
This gets parameter qualifiers to the parameters and thus `const`
parameters work as expected (even passes validation). However,
in/out/inout do not work yet due to incorrect setup of the function
call: spir-v wants them to be passed by reference (pointers) rather than
by value.
The function parameter and argument types are a mess with respect to
references (and thus calls don't pass validation) but the generated code
seems to be otherwise correct.
It wasn't quite as nasty as I thought, but splitting it up helps add a
little self documentation and, possibly more importantly, simplify
navigation through the type checks and argument setup.
I've long felt build_function_call was getting a bit big, and expr.c
especially so. This should make it easier to rewrite build_function_call
for dealing with target-specific code. As a bonus, the int through ...
warning is already cleaned up.
spir-v uses SSA, so temps cannot be assigned to directly, so instead use
the temp expression as a reference for the result id of the rhs of the
assignment. This would get function calls working if the they actually
emitted any code (right now, just a place-holder id so spirv-dis doesn't
fall over).
Also, fix some missing docs. Unfortunately, there are still some
problems (incorrect resolution for multiple files/functions with the
same name, and a bug with doxygen's verbatim/code blocks).
Ruamoko and v6(p) have their own copies despite being (currently) the
same, and spir-v's is currently empty, but now targeting spir-v doesn't
try to emit ruamoko code.
While a reference var can't be initialized yet, using them seems to work
in that they get dereferenced when the value needs to be read or written
(though I haven't seen any generated code for them yet).
I don't know why the last argument was handled differently. I suspect it
was a hold-over from before I added list handling. Removing it seems to
have made no significant difference (all tests pass still).
When the parameter is a reference, implicit casting is not allowed, but
when the parameter is by value and the argument is a reference, the
argument is dereferenced and promotion is allowed.
However, this covers only the selection of generic functions. It doesn't
deal with otherwise overloaded functions, nor does it do the actual
dereferencing or address taking.
Before adding references, looking at just type.type was ok whether or
not the type was an alias, but checking the deref flag needs the type to
be basic and not alias.
Simple functions now get to the code-gen phase (where they fail since
it's the wrong for other reasons). Parameter types aren't right for
spir-v yet as non-const params need to be references.
I realized that spir-v pointers are essentially references (the way
they're used) since OpVariable requires a pointer type rather than the
base type. Thus, under the hood, references are just pointers with
automatic dereferencing. However, nothing uses references yet, and I
expect to run into issues with is_pointer vs is_reference vs is_ptr
(high-level pointer, reference, low-level pointer, respectively).
Since begin_function creates the parameter and locals scopes, there's no
need for another scope for the function body. This fixes the detection
of shadowed parameters for Ruamoko and QuakeC.
It's currently passing for Ruamoko, but glsl doesn't catch shadowed
params. There's a bit of a conflict and I want to make sure I don't lose
the checking.
I'd gotten tired of all the convoluted progs version checks, and with
the addition of spirv, they're not even always relevant, and adding C
(when I get to it) will make things even worse. However, for now the
first victim is just the parameter/return value size check.
Now declarations can be deferred too, thus things like generic/template
and inline functions should be possible. However, the most important
thing is this is a step towards a cleaner middle layer for compilation,
separating front-end language from back-end code-gen.
I don't remember why I thought it was a good idea at the time, but I
decided that having the union was a bit iffy and making the list
"official" would be a good idea. In the end, it removed a nice chunk of
code (redundant list manipulations).
And they even pass validation (though it turns out there's a bug in
glslangValidator regarding specialization constants with expressions (or
possibly spirv-val, but it seems to be the former as my bug report shows
signs of activity in that direction)).
https://github.com/KhronosGroup/glslang/issues/3748
