Re: [Gcc4cli-devel] Several small patches

[Gabriele S. <gab...@gm...>]

 Hi Thierry.

2010/3/8 Thierry Lafage <thi...@in...>:
> Hi all,
>
> Here are several small patches for our gcc4cli BE branch:
>
> pr19340.c.patch is to avoid testing with pr19340.c because it has no sense
> in cil32 since it tests the scheduler.
> gcc4cli_line_info-t-cil32.patch fixes dependencies in t-cil32 and adds the
> file source-location.h which was introduced in my last patch concerning
> source location (this t-cil32 patch should have been part of the source
> location patch).
> cil-lower.c.patch modifies the pass gate in order to activate this pass only
> when -ftree_vectorize option is activated (which is the case in -O3)

Unfortunately you cannot do this as the users can explicitly use
vector intrinsics in the code even if -O3 is not specified. Under
those conditions you will find vector operations even if you are
compiling with -O0, it happens quite often in the testsuite BTW.

> and simp-cond.patch is a simplification of the simp-cond pass which also
> makes it more complete (adds support for brtrue/brfalse and for floating
> point comparisons in conditional branches + add a command-line option which
> is activated in -O1 + fixes missing brtrue/brfalse as being conditional
> branch instructions). Note that this pass either does nothing, or change a
> branch condition instruction into another one (inverts the condition) and
> removes the following unconditional branch. This means that the stack is not
> changed at all, so I removed all the stuff that was recomputing the stack at
> every statement. Moreover, I didn't understand the test on the conditional
> branch operand type (integer or pointer) in order to change the conditional
> br instruction: I've removed it and tested on a real program, and it seems
> to be ok.

You cannot remove the integer / pointer test from that pass because
for floating-point numbers those operations cannot be changed. For
example if 'x' and 'y' are two floating-point NaNs the result from any
comparison will always be unordered, i.e. x > y and x <= y will both
evaluate to false hence you cannot invert the comparison. That's why I
left out floating-point comparisons and that's why I compute the
stack: I need to know on what types the comparison is working on. As
for brtrue and brfalse I don't remember why I have left them out. They
are different from the other instructions in that they pop off the
stack a single value and work only on native integers while other
comparisons pop two values which can be pretty much anything. I might
have left them out because of that but I don't remember exactly so you
might give them a try anyway. A full testsuite will give you the
answer anyway, if there are problems tied to swapping brtrue/brfalse
they will probably manifest themselves there.

 Gabriele