llvm dev - Aug 2016 - LLVM 3.9 RC2's SCCP pass removing calls to external functions?!

On Wed, Aug 24, 2016 at 10:11 AM, Renato Golin <renato.golin at
linaro.org>
wrote:
> On 24 August 2016 at 08:48, Alexandre Isoard via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I am probably stating the obvious, but if the function is side-effect
> free
> > (onlyReadsMemory) it is valid to remove it.
> >
> > But I am guessing that does not belong to this pass.
>
> I think it does.
>
> This is a very aggressive pass that does all sorts of inter-procedural
> cleanups, and unused side-effect free function calls is just the
> thing.
I see. Then I agree.
>
> It looks to me that the compiler just got a bit more picky and your
> original assumption was wrong to begin with.
>
However, he also stated that in the case the functions returns void it is
not removed, which suggest there is something fishier going on.
>
> Maybe your project needs to tell the middle-end (via function
> attributes) that the function does have side effects?
>
> cheers,
> --renato
>


-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160824/5ff0172a/attachment.html>

On 24 August 2016 at 11:45, Alexandre Isoard <alexandre.isoard at
gmail.com> wrote:
> However, he also stated that in the case the functions returns void it is
> not removed, which suggest there is something fishier going on.
Looking back at the example (and LangRef, for function attributes),
looks like it's not legal to remove because the function does *not*
have "readnone" or "readonly", so LLVM can't prove it
side-effect
free.

Sanjoy's fix is probably on the right track.

--renato

Yes, there is no way for any pass to find out by itself whether that function
has side effects, and I didn't tell it that it doesn't have any, so that
seems overly aggressive.

As far as finding and fixing the problem goes: I used to build LLVM and Clang
from source, but I stopped because a full build takes around 3 hours on this
machine and I don't get a lot out of it. I use LLVM on my spare time and
I'm about as casual as a compiler back-end user can be. Sanjoy, I'd be
happy if you looked into it.

Félix
> Le 24 août 2016 à 05:47:46, Renato Golin <renato.golin at linaro.org>
a écrit :
> 
> On 24 August 2016 at 11:45, Alexandre Isoard <alexandre.isoard at
gmail.com> wrote:
>> However, he also stated that in the case the functions returns void it
is
>> not removed, which suggest there is something fishier going on.
> 
> Looking back at the example (and LangRef, for function attributes),
> looks like it's not legal to remove because the function does *not*
> have "readnone" or "readonly", so LLVM can't prove
it side-effect
> free.
> 
> Sanjoy's fix is probably on the right track.
> 
> --renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160824/5327d096/attachment.html>

Actually, this is false.
It will infer the attribute :)



On Wed, Aug 24, 2016 at 5:47 AM, Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 24 August 2016 at 11:45, Alexandre Isoard <alexandre.isoard at
gmail.com>
> wrote:
> > However, he also stated that in the case the functions returns void it
is
> > not removed, which suggest there is something fishier going on.
>
> Looking back at the example (and LangRef, for function attributes),
> looks like it's not legal to remove because the function does *not*
> have "readnone" or "readonly", so LLVM can't prove
it side-effect
> free.
>
> Sanjoy's fix is probably on the right track.
>
> --renato
> _______________________________________________
> 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/20160824/1b1ffc59/attachment.html>