[LLVMdev] Instructions that cannot be duplicated

[Mon Ping Wang]

Yes, this is the case.   The platforms I'm thinking of don't support  
function calls and have the optimization-hostile barrier instructions.

   -- Mon Ping



On Oct 9, 2009, at 10:46 AM, Jeffrey Yasskin wrote:

> Are the platforms with no function calls the same ones that have
> optimization-hostile barrier instructions? If the two sets of
> platforms are disjoint, OpenCL implementers can use my or Devang's
> noinline-function technique on the optimization-hostile platforms, and
> inject a unique argument into the barrier() call in the frontend on
> the no-function platforms.
>
> On Fri, Oct 9, 2009 at 3:34 AM, Mon Ping Wang <monping at apple.com>  
> wrote:
>>
>> Point taken :->.  Inlining of these functions containing these
>> barriers are required on some platforms.  The only restriction is  
>> that
>> any control flow optimization must preserve the property that all
>> threads will hit the same barrier.
>>
>> -- Mon Ping
>>
>> On Oct 9, 2009, at 2:22 AM, Eli Friedman wrote:
>>
>>> On Fri, Oct 9, 2009 at 12:20 AM, Mon Ping Wang <monping at apple.com>
>>> wrote:
>>>>
>>>> The requirement in OpenCL is that all threads (work-items) are
>>>> required to
>>>> hit the same barrier.  If one does what you have shown below, it is
>>>> not
>>>> legal because some threads may go through the block with S1 and
>>>> some other
>>>> threads will go the other way.  On some hardware, such a program
>>>> will cause
>>>> a hardware stall. If one is inlining, it is preferable to inline
>>>> early
>>>> assuming the rest of the transformations don't mess with the
>>>> barrier. Eli is
>>>> correct that you can't duplicate calls to a function containing
>>>> these kind
>>>> of barriers for the same reasons.  From the discussions so far, it
>>>> would be
>>>> nice if such a concept where you don't want to modify the control
>>>> flow of a
>>>> basic block containing such an execution barrier or a function
>>>> containing
>>>> such a barrier. This requires that all phases that does such
>>>> optimizations
>>>> would have to be made aware of it.  Such a concept 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
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev