[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
Sun, 22 Feb 2015 00:28:24 +0000
Michael Matz <address@hidden>:
> Well, I'd hope we can do a bit better than this. For instance by
> introducing a new function that does what lvalue_type does, _plus_
> the VT_LLOCAL handling, plus changing vtop->r (or any given
Yes, perhaps, though sometimes lvalue_type is called in places where
there isn't an "r" to work on, I think.
> >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.
> I think the conversion to rvalue might not actually have to emit
> code, in which case unused stuff would be as optimized as before (as
> far as tcc is optimizing :)).
I can't see how to do that.
> >Since I probably still have a test case to hand, should I propose
> >an alternative patch that fixes my problem by modifying gen_op?
> Yeah, I think so.
So here's an alternative patch that fixes the problem for me:
diff --git a/tccgen.c b/tccgen.c
index ae07563..9dfeb2b 100644
@@ -1827,6 +1827,8 @@ ST_FUNC void gen_op(int op)
vtop->type.t = t;
+ if (vtop->r & VT_LVAL)
+ gv(is_float(vtop->type.t & VT_BTYPE) ? RC_FLOAT : RC_INT);
It probably doesn't change the generated code significantly, though I
should perhaps warn that apart from the cases I alluded to earlier,
where a value computed is not used, there may also be a few cases
where converting the value to an rvalue earlier than it is needed
hurts the register allocation, as in something like f(a + 0, b + 0, c
+ 0, d + 0, e + 0, f + 0). I wouldn't worry about it, though.
I've just noticed that the patch above doesn't have the comment I
wrote, something like:
+ // Make sure that we have converted to an rvalue:
Do you like this new patch?
I need to fix this problem somehow for arm64.