Re: [Gcc4cli-devel] Several small patches

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

 Hi Thierry,

2010/3/9 Thierry Lafage <thi...@in...>:
> Hi Gabriele,
>
> Ok, sorry, I misunderstood the fixme "should lower only if vector types are
> handled in this funtion."
> I simply wanted, for easier debug, to ensure that the execution of this pass
> could be controlled (ie. skipped by using a command-line argument). But it's
> probably useless.

such a flag might be useful but you should talk to Erven about it, he
was the one who wrote the pass IIRC.

> Ok, for this one, I've been very naive. Sorry. It seems to me that it has
> been a fast copy/paste of a generic pass...

I know, it certainly looked like it, in fact it was a rewrite of a
pass we did on the tree representation before we introduced the CIL
representation in the back-end.

> For true/false, it happens that conditions on floating point values may be
> computed by first using a comparison, and then a brtrue or brfalse. So
> inverting the branch may lead to the same problems as with branches with FP
> operands.

OK, that must be why I've left it out.

> In this particular case, we could look up at the operands of the
> compare (if any) and invert the branch (or better: the compare itself?) only
> if they are integer or pointers.

Yes, it might work. Anyway the GCC testsuite will show you if there
are any problems with this approach, I know it's very long and boring
to run it but it's the best way to spot hard-to-find errors. I believe
I tried switching the floating-point comparisons in the first place
and switched back to integers only after checking with the testsuite
myself.

> For the FP general case, wouldn't it be possible to use *.un (or not)
> versions of the branches? I'll make tests to check.

Yes, if you are very careful you can change some of the conditions by
using the appropriate unordered comparisons. However you should also
verify with the mono JIT compiler if it is worth to do it: many
architectures do not have the full range of floating-point
ordered/unordered comparisons so on those architectures using them
will result in very poor native code at JIT time. After considering
all the problems I decided not to touch them because the chance of
introducing some serious regressions was fairly high and the gain was
very little.

> However, concerning stack computation, since conditional branch inversion
> does not change the stack at all, are the "cil_stack_after_stmt (stack,
> stmt);" and "FOR_EACH_EDGE(...) { cil_set_stack_for_bb (...); }" useful?
> I understand these statements as being a stack re-compute, isn't it?

Yes, those compute the effect of an operation on the stack and
propagate them to target basic-blocks at the end of the loop. We need
them in order to know what are the types of the stack operands,
however they are very cheap operations, I specifically designed them
so that we don't need to fully recalculate the stack at every point.
Instead cil_stack_after_stmt() will update the provided stack with
only the changes caused by the specified instruction providing you
with an up-to-date state of the stack.

 Gabriele