[LLVMdev] How to prevent duplication of function calls?

[Rotem, Nadav]

Hi, 

I wanted to start the 'barrier duplication' discussion again.  Last time around Eli proposed to add a new attribute "executebarrier" which will prevent the duplication of barriers.  I am considering implementing this feature.  Anyone opposes this approach, or had already implemented it ?

Thanks,
Nadav

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah
Sent: Monday, April 18, 2011 20:40
To: 'llvmdev at cs.uiuc.edu'
Subject: Re: [LLVMdev] How to prevent duplication of function calls?

Dmitry,
 We never were able to get a resolution for this issue. What we have done is made modifications to LLVM to disable duplication of barrier in specific optimization passes. Once we fully integrate with 2.9 we plan on attempting to merge some of those changes back in to LLVM.

Micah

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Dmitry Denisenko
> Sent: Monday, April 18, 2011 7:45 AM
> To: 'Reid Kleckner'
> Cc: 'llvmdev at cs.uiuc.edu'
> Subject: Re: [LLVMdev] How to prevent duplication of function calls?
> 
> Thanks Reid. It looks like the first thread didn't really get anywhere.
> The author most likely just modified the offending passes to respect 
> the barriers (this is my guess based on what I read in that thread).
> 
> By the time back-end starts, it's too late, since the front end does 
> some of the duplications.
> 
> For the record, I probably will end up doing the following:
> - Modifying passes that duplicate the calls not to do so.
> - Marking all barrier calls with a new global variable.
> - Assert that no duplication happened (i.e. there are no two barriers 
> that access the same global marker). If that happens, tell the user to 
> turn down optimizations until the assert failure goes away :(.
> 
> This is a maintenance problem but probably still easier than writing 
> generic re-merging pass.
> 
> 
> Dmitry
> 
> 
> -----Original Message-----
> From: Reid Kleckner [mailto:reid.kleckner at gmail.com]
> Sent: Saturday, April 16, 2011 2:33 PM
> To: Dmitry Denisenko
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] How to prevent duplication of function calls?
> 
> This came up a long time ago, but I'm not sure what the resolution was:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-October/026312.html
> 
> There's also TID::isNotDuplicable:
> http://llvm.org/docs/doxygen/html/classllvm_1_1TargetInstrDesc.html#ab
> 0
> 5b074805f22503828b5b625d437f3a
> 
> I don't know enough about LLVM's backend to say if you can get that on 
> an intrinsic.
> 
> Reid
> 
> On Thu, Apr 14, 2011 at 5:24 PM, Dmitry Denisenko 
> <DDENISEN at altera.com>
> wrote:
> > Hello,
> >
> >
> >
> > Is it possible to prevent duplication of call sites for specific
> functions
> > (while still maintaining –O3 optimization level)? For example, the
> following
> > C code:
> >
> >
> >
> > ------------------
> >
> > if (cond1) a=2;
> >
> > llvm.memory.barrier(...);
> >
> > ------------------
> >
> >
> >
> > is turned by clang with -O2 into something like this:
> >
> >
> >
> > ------------------
> >
> > if (cond1)
> >
> >           a=2;
> >
> >           llvm.memory.barrier(...);
> >
> > else
> >
> >           llvm.memory.barrier(...);
> >
> > ------------------
> >
> >
> >
> > We’re doing C to HDL compilation with LLVM. Having multiple 
> > locations
> that
> > call llvm.memory.barrier(...) would cause complications to generated 
> > hardware.
> >
> >
> >
> > So far, I can think of only two solutions. One is to add support for 
> > something like “noclone” attribute and update all optimizations to
> obey it.
> > The other is to re-merge the calls as a final pass. Any better ideas?
> >
> >
> >
> > Thank you,
> >
> > Dmitry
> >
> >
> >
> > ________________________________
> > Confidentiality Notice.
> > This message may contain information that is confidential or
> otherwise
> > protected from disclosure. If you are not the intended recipient, 
> > you
> are
> > hereby notified that any use, disclosure, dissemination,
> distribution, or
> > copying of this message, or any attachments, is strictly prohibited.
> If you
> > have received this message in error, please advise the sender by
> reply
> > e-mail, and delete the message and any attachments. Thank you.
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or otherwise 
> protected from disclosure. If you are not the intended recipient, you 
> are hereby notified that any use, disclosure, dissemination, 
> distribution,  or copying  of this message, or any attachments, is 
> strictly prohibited.  If you have received this message in error, 
> please advise the sender by reply e-mail, and delete the message and 
> any attachments.  Thank you.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.