[llvm-dev] Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?

[David Blaikie via llvm-dev]

On Fri, Mar 18, 2016 at 8:33 AM, Chuang-Yu Cheng <
cycheng at multicorewareinc.com> wrote:

> 1. Same question as David, why &c - 8 is invalid? Is it related to below
> statements In C99 standard?
>
> 6.5.3.3:
> "Among the invalid values for dereferencing a pointer by the unary *
> operator are a null pointer, an
> address inappropriately aligned for the type of object pointed to, and the
> address of an object after the
> end of its lifetime."
>
> 2. We are trying to preserve 1st load and remove other loads now, because
> our test pattern can not get rid of "-fno-strict-aliasing", and additional
> loads hurt performance. We did some change in SROA::runOnAlloca, we try to
> do something like this:
>
> void qux(PB* _c) {
>   PB* c;         <= insert this for original code
>   bar(&_c);
>
>   c = _c;        <= insert this for original code
>   c->f1_ = 0;
>   c->f2_ = 0.f;
> }
>

Not sure I quite understand the question - if we believe GCC's
interpretation to be incorrect/Clang's to be correct, there's nothing our
optimizers can do to correct the code & free us up to do the optimization
GCC does here.

If you're talking about modifying your code to allow Clang to optimize it
better - yes, it seems like if you copy the pointer:

void qux(PB* _c) {
  bar(&_c);
  PB *c;
  c->f1_ = 0;
  c->f2_ = 0.f;
}

Should do the right optimization, because there's no way that 'bar' could
give _c an address that would alias 'c' in any way.

I'm not sure what you're referring to when you mention making changes to
SROA.

- Dave


>
> Any opinions please let us know.
> Thanks!
>
> CY
>
> On Fri, Mar 18, 2016 at 11:24 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
>
>> Why would computing that pointer be invalid?
>>
>> (I could imagine, if there was no object behind c to point to it would be
>> invalid - but that's a dynamic property of the program that the compiler,
>> given this code, can't prove /isn't true/ (the programmer might've
>> constructed the caller such that it does always have an object behind 'c'
>> to point to))
>>
>> On Fri, Mar 18, 2016 at 1:28 AM, Markus Trippelsdorf via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On 2016.03.17 at 16:35 -0700, Chris Lattner via llvm-dev wrote:
>>> >
>>> > > On Mar 15, 2016, at 7:58 AM, Chuang-Yu Cheng via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > Please look at this c code:
>>> > >
>>> > > typedef struct _PB {
>>> > >   void* data;  /* required.*/
>>> > >   int   f1_;
>>> > >   float f2_;
>>> > > } PB;
>>> > >
>>> > > PB** bar(PB** t);
>>> > >
>>> > > void qux(PB* c) {
>>> > >   bar(&c);              /* c is escaped because of bar */
>>> > >   c->f1_ = 0;
>>> > >   c->f2_ = 0.f;
>>> > > }
>>> > >
>>> > > // gcc-5.2.1 with -fno-strict-aliasing -O2 on x86
>>> > > call    bar
>>> > > movq    8(%rsp), %rax
>>> > > movl    $0, 8(%rax)
>>> > > movl    $0x00000000, 12(%rax)
>>> > >
>>> > > // llvm 3.9.0 with -fno-strict-aliasing -O2 on x86
>>> > > callq    bar
>>> > > movq    (%rsp), %rax
>>> > > movl    $0, 8(%rax)
>>> > > movq    (%rsp), %rax
>>> > > movl    $0, 12(%rax)
>>> > >
>>> > > You can see that llvm load "c" twice, but gcc only load "c" once.
>>> > > Of course, in bar function, you may do something very dangerous, e.g.
>>> > >
>>> > > PB** bar(PB** t) {
>>> > >    *t = (PB*) t;
>>> > > }
>>> > >
>>> > > But gcc doesn't care bar's definition.
>>> > > Is llvm too conservative, or gcc too aggressive in this pattern?
>>> >
>>> > In my opinion, in the face of -fno-strict-aliasing, GCC is being too
>>> > aggressive.  It would be interesting to hear what they think.
>>>
>>> We discussed this issue briefly on the #gcc IRC channel.
>>> Richard Biener pointed out that bar cannot make c point to &c - 8,
>>> because computing that pointer would be invalid. So c->f1_ cannot
>>> clobber c itself.
>>>
>>> --
>>> Markus
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160318/f2122bbc/attachment.html>