[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

[Hal Finkel]

----- Original Message -----
> From: "Renato Golin" <renato.golin at linaro.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Arch Robison" <arch.robison at intel.com>, "LLVM Dev"
> <llvmdev at cs.uiuc.edu>
> Sent: Wednesday, August 20, 2014 2:16:56 PM
> Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"
> 
> On 20 August 2014 18:24, Hal Finkel <hfinkel at anl.gov> wrote:
> > Also, we should probably allow for missing access numbers, so long
> > as everything is in order (because the optimizer might eliminate
> > some of them). Some memory-access instructions might also have
> > more than one access number (after GVN, vectorization, etc.), and
> > we should allow for that.
> 
> What about inlining? Say metadata IDs 1, 2, 3 from loop 1 are inlined
> onto metadata 1, 2, 3 from loop 2. You'll end up with 1, 2, 3, 1, 2,
> 3, what does that mean? Then, an optimization pass removes 1, 2,
> leaves 3, 1, and deletes 2, 3. Does that mean they're out of order?

I don't understand. I think that the numbering would need to be specific to the loop id.

 -Hal

> 
> Inlining will probably have to learn how to re-order in every linined
> to loops while still keeping the original ids on the original loops.
> That will also involve adding N to the { M+1 ~ K } set that were left
> after the inlining N nodes at position M.
> 
> cheers,
> --renato
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory