This is the mail archive of the
mailing list for the GCC project.
Re: Anyone used Graphite of Gentoo recently?
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Tobias Grosser <tobias at grosser dot es>
- 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 10:10:18 +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>
On Mon, Mar 31, 2014 at 8:23 AM, Tobias Grosser <firstname.lastname@example.org> wrote:
> On 03/31/2014 06:25 AM, Vladimir Kargov wrote:
>> On 27 March 2014 18:39, Mircea Namolaru <email@example.com> wrote:
>>> The domain is computed on basis of the information provided by
>>> number_of_latch_execution that returns the tree expression
>>> (unsigned int) maxLen_6(D) - (unsigned int) minLen_4(D)
>>> For signed integers (without the cast to unsigned int) this seems to be
>>> correct value. As an unsigned int expression it leads to incorrect
>> I've got a couple of questions with regards to wrapping. Pasting the
>> relevant code from graphite-sese-to-poly.c:
>> static isl_pw_aff *
>> extract_affine (scop_p s, tree e, __isl_take isl_space *space)
>> // e comes from number_of_latch_executions()
>> type = TREE_TYPE (e);
>> if (TYPE_UNSIGNED (type))
>> res = wrap (res, TYPE_PRECISION (type));
>> 1) Any idea why wrapping occurs only for unsigned expressions?
> In the C standard, unsinged operations have defined overflow semantics in
> form of wrapping. Signed operations instead have undefined behavior, which
> means we can assume that no wrapping occurs and consequently do not need to
> model it.
>> 2) What exactly is wrapping needed for? I can't find it in the old PPL
>> implementation (though it could have been called differently).
> it is necessary to model the defined overflow behavior of unsigned integers.
>> Also, no matter what the logic behind wrapping is, it does seem
>> suspicious that this code checks the signedness of the result of
>> number_of_latch_execution() (which may be arbitrary, as far as I
>> understood), and not of the loop induction variable, for example.
> It is very suspicious. It is a rather difficult topic and I doubt it is
> implemented correctly. Also, I do not think that implementing wrapping this
> way is the right approach. Instead, we should just model it to
> extract a run-time check that verifiers that no wrapping occurs and then go
> one without wrapping.
> 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)
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.