This is the mail archive of the
mailing list for the GCC project.
Re: Anyone used Graphite of Gentoo recently?
- From: Tobias Grosser <tobias at grosser dot es>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Vladimir Kargov <kargov at gmail dot com>, Mircea Namolaru <mircea dot namolaru at gmail dot com>, GCC GRAPHITE <gcc-graphite at googlegroups dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 31 Mar 2014 13:53:03 +0200
- Subject: Re: Anyone used Graphite of Gentoo recently?
- Authentication-results: sourceware.org; auth=none
- References: <70da25b6-e3d9-4b9b-acc5-24b2f1ddc174 at googlegroups dot com> <52E218AA dot 60608 at grosser dot es> <52E3E1CC dot 3090505 at gmail dot com> <52E40D66 dot 7080800 at grosser dot es> <52E48469 dot 7020804 at gmail dot com> <52EF8D4F dot 4040204 at grosser dot es> <52F313FA dot 8090709 at gmail dot com> <52F33C8D dot 3050807 at grosser dot es> <52FE1B4C dot 2030206 at gmail dot com> <52FEC77C dot 4040403 at grosser dot es> <CAHLdKikqiENxq4N2r2FD2FhjYB3hMGDjZ-LkAU18V0-q+yLs9g at mail dot gmail dot com> <5335793C dot 80603 at grosser dot es> <CAHLdKin_yKBrgUTGL6s+xnYd-cwYnLqpig0tL7cXq=TnYVHtuw at mail dot gmail dot com> <CAHLdKinPE_yHPMU41b9D=QY1CO0UA0t2DXYw=41g-+6NVoQwdQ at mail dot gmail dot com> <533909FB dot 6020300 at grosser dot es> <CAFiYyc2fASHUNUL06fqBQ_=EzsR569V6aKRNYayAZYCsOf09xw at mail dot gmail dot com>
On 03/31/2014 10:10 AM, Richard Biener wrote:
On Mon, Mar 31, 2014 at 8:23 AM, Tobias Grosser <email@example.com> 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
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.