On Sat, Feb 11, 2012 at 10:17 AM, Tobias Grosser <tobias at grosser.es>
wrote:> On 02/10/2012 11:29 PM, Sebastian Pop wrote:
>> On Fri, Feb 10, 2012 at 3:53 PM, Devang Patel<dpatel at
apple.com> wrote:
>>> How would you tie a built-in call with a loop ?
>>
>> The same way as Hal was saying: tag the loop header.
>
> So how do we tag the loop header? ;-)
>
> If we just put the instruction in the header, in the worst case LICM
> will move it to header basic block of another loop. :-(
I don't think that optimizers are going to touch a builtin call for which
they don't understand the side effects. If they do, then they will get
what they deserve: bug reports.
> We could try to keep it somehow attached to the loop. E.g. by making it
> modify a scalar that is changed in each loop iteration. But than again,
> some sophisticated loop fission pass may move these instructions apart.
> We definitely need some conventions for such an approach. Another issue
> is, that as more semantics we put into such a loop marking instruction,
> the more probable it is that we block optimizations like dead code
> elimination of the entire loop. If we do not put any semantics, we may
> risk to loose the annotation.
>
> Another option that I see is somehow in the direction of what Devang
> pointed out. We could make our intention of maintain information about
> the loops more explicit. I could e.g. imagine having some permanent
> pass/analysis, maybe called LoopInformationManager, that is in charge of
> the loop meta data. When reading LLVM-IR it initializes itself by
> reading the loop meta-data. Other passes can call the
> LoopInformationManager for the information they are interested in.
> Passes that do not touch the loop structure need to explicitly specify
> that they preserved the loop semantics. In case this is not done, the
> LoopInformationManager removes the meta-data from the loop. Or in case
> it is informed about a change, it adapts the meta-data accordingly. Such
> that at the end, only valid meta-data will be written out.
> This approach has its own drawbacks, but it may be a direction we could
> consider.
I think that storing information on the side is good for the results of a
program analysis that can be recomputed if the information is lost.
On the other hand, the information that the programmer has put in a
pragma cannot be recomputed, and so in my opinion that should be
part of the IR.
Sebastian
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum