On 03/31/2014 10:10 AM, Richard Biener wrote:
On Mon, Mar 31, 2014 at 8:23 AM, Tobias Grosser <tob...@grosser.es> wrote:
On 03/31/2014 06:25 AM, Vladimir Kargov wrote:
Regarding this bug there are two directions to go:
1) It is necessary to understand if we need to do wrapping on the result of
number_of_latch_executions. Meaning, we should understand the semantics of
this function and the expression it returns.
2) There is something else happening?? From my observations it seems
that the generated code at least for this test case should behave correctly
and the relevant loop should be executed exactly twice. Surprisingly this is
not the case. It would be interesting to understand what exactly prevents
this loop from being executed. (From the clast, this is not obvious to me).
Note that there are always two sides of the "undefined overflow" thing
1. in the input IL whether an operation may overflow or not (check
TYPE_OVERFLOW_UNDEFINED, _not_ !TYPE_UNSIGNED)
Thanks Richi. I was not aware of this, but we really should check for
TYPE_OVERFLOW_UNDEFINED instead.
I think for now we may want to limit ourselves to
TYPE_OVERFLOW_UNDEFINED, as the wrapping code is not very reliable and
will cause very ugly code.
2. in the GIMPLE IL generated from clast - all operations that satisfy
TYPE_OVERFLOW_UNDEFINED may not have different overflow behavior
than in the original untransformed program (no intermediate overflows
unless they were already present). Usually that's not very easy to guarantee,
thus re-writing everything into unsigned arithmetic may be easiest.
The code we generate should not have any overflows. In case there are
earlier defined overflows we should at best bail out. This is the safest
approach. Anything else requires some more investigations.
Cheers,
Tobias
