[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] [PATCH] When handling '.' operator, cope with VT_LLOC
Edmund Grimley Evans
Re: [Tinycc-devel] [PATCH] When handling '.' operator, cope with VT_LLOCAL
Sat, 21 Feb 2015 23:21:25 +0000
Michael Matz <address@hidden>:
> Do you have a testcase?
I made the change after something in abitest failed with the arm64
back end, but with a newer version than the one I sent to the list.
> is: this patches only one place where lvalue_type is called (i.e.
> where something on the stack is lvalueized again).
The function lvalue_type isn't just used to "lvalueise" things, and
there may be places where the stack is lvaluised without calling
> Why are the
> others trivially correct and don't need such handling?
I expect there are many bits of code that are wrong but which happen
never to receive the values that they can't handle.
How many parts of tccgen.c can correctly handle a VT_REF, do you
> conceptually, I might have a problem with this: it fixes up things
> after they went wrong. For instance, why isn't the problem in
> gen_op? I mean, one invariant of gen_op (when called with
> non-optimizable args) is that it leaves a non-lvalue on the stack,
> so the code in unary() is correct as is, for those cases. So,
> wouldn't it be better if the lvalue-to-rvalue conversion would
> happen also with gen_op(+,0)?
The advantage of making gen_op always convert to an rvalue is that
other code would have to worry about fewer cases.
The only disadvantage that I can think of is that certain expressions
which would cause GCC to warn that "value computed is not used" would
not get optimised.
So, if you're suggesting that gen_op should be modified to always
convert to an rvalue, then I think I agree. Shall we do that instead?
Since I probably still have a test case to hand, should I propose an
alternative patch that fixes my problem by modifying gen_op?