search for: executebarrier

...mark it noinline. This way the instruction pointers will > > be unique to the barrier. > > No, this gets rather nasty: to support an instruction like this, it > isn't legal to duplicate calls to functions containing a barrier > instruction. > > Another proposal: add an executebarrier function attribute for > functions which directly or indirectly contain an execution barrier, > and adjust all the relevant transformation passes, like jump threading > and loop unswitching, to avoid duplicating calls to such functions. > This puts a slight burden on the frontend to mar...

...may be also useful for > other things like inline assembly where one may not want to duplicate a > block. It's probably worth noting that I wasn't proposing a general prohibition of duplication; it would be okay for inlining or loop unrolling to duplicate a call to a function marked executebarrier. It's not the same sort of prohibition that one might want for inline assembly. -Eli

...barrier in the > program, and mark it noinline.  This way the instruction pointers will > be unique to the barrier. No, this gets rather nasty: to support an instruction like this, it isn't legal to duplicate calls to functions containing a barrier instruction. Another proposal: add an executebarrier function attribute for functions which directly or indirectly contain an execution barrier, and adjust all the relevant transformation passes, like jump threading and loop unswitching, to avoid duplicating calls to such functions. This puts a slight burden on the frontend to mark functions appropri...

...things like inline assembly where one may not want to >> duplicate a >> block. > > It's probably worth noting that I wasn't proposing a general > prohibition of duplication; it would be okay for inlining or loop > unrolling to duplicate a call to a function marked executebarrier. > It's not the same sort of prohibition that one might want for inline > assembly. > > -Eli > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/...

...t noinline. This way the instruction pointers > will > > be unique to the barrier. > > No, this gets rather nasty: to support an instruction like this, it > isn't legal to duplicate calls to functions containing a barrier > instruction. > > Another proposal: add an executebarrier function attribute for > functions which directly or indirectly contain an execution barrier, > and adjust all the relevant transformation passes, like jump threading > and loop unswitching, to avoid duplicating calls to such functions. > This puts a slight burden on the frontend to mar...

...sembly where one may not want to >>> duplicate a >>> block. >> >> It's probably worth noting that I wasn't proposing a general >> prohibition of duplication; it would be okay for inlining or loop >> unrolling to duplicate a call to a function marked executebarrier. >> It's not the same sort of prohibition that one might want for inline >> assembly. >> >> -Eli >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu >&g...

...want to >>>> duplicate a >>>> block. >>> >>> It's probably worth noting that I wasn't proposing a general >>> prohibition of duplication; it would be okay for inlining or loop >>> unrolling to duplicate a call to a function marked executebarrier. >>> It's not the same sort of prohibition that one might want for inline >>> assembly. >>> >>> -Eli >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu...

On Thu, Oct 8, 2009 at 3:59 PM, Devang Patel <devang.patel at gmail.com> wrote: > On Thu, Oct 8, 2009 at 11:28 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: >> >> >>> -----Original Message----- >>> From: Jeffrey Yasskin [mailto:jyasskin at google.com] >>> Sent: Thursday, October 08, 2009 11:09 AM >>> To: Villmow, Micah

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

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