Displaying 5 results from an estimated 5 matches for "nooverlap".
2015 Aug 21
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
Hi Hal
> By this I assume you mean some new 'nooverlap' metadata? I don't think we
have any existing metadata with the correct semantics.
I was thinking we could just use the existing noalias metadata. Implicitly,
the current llvm.memcpy semantics are "src and dst overlap perfectly or not
at all" (perhaps we should update the docs to...
2015 Sep 08
2
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
..."Gerolf Hoflehner" <ghoflehner at apple.com>
> > Sent: Friday, August 21, 2015 1:02:18 AM
> > Subject: Re: [llvm-dev] [RFC] Generalize llvm.memcpy / llvm.memmove
> intrinsics.
> >
> > Hi Hal
> >
> > > By this I assume you mean some new 'nooverlap' metadata? I don't
> > > think we have any existing metadata with the correct semantics.
> >
> >
> > I was thinking we could just use the existing noalias metadata.
> > Implicitly, the current llvm.memcpy semantics are "src and dst
> > overlap per...
2015 Aug 20
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...f can prove that src !=
> destination, which is often easier than proving things accounting for
> overlaps.
>
>
> Is this limited to the memcpy case or are these other use-cases so that it
> would be worth having another attribute than noalias that would carry this
> semantic (“nooverlap”)?
>
>
> I was wondering about that, too. This looks like information either the
> user has or the compiler could derive. Would it be best to condense the
> properties into *alias* and *align* attributes that are also user visible?
>
>
> —
>
> Mehdi
>
>
>
>...
2015 Aug 19
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...still make aliasing assumptions if can prove that src != destination, which is often easier than proving things accounting for overlaps.
Is this limited to the memcpy case or are these other use-cases so that it would be worth having another attribute than noalias that would carry this semantic (“nooverlap”)?
—
Mehdi
>
>>>>
>>>>
>>>>
>>>> (2) Allow different source and destination alignments on both
>>>> llvm.memcpy / llvm.memmove.
>>>>
>>>> Since I'm talking about changes to llvm.memcpy anyway, a few...
2015 Aug 19
2
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
On 08/19/2015 09:35 AM, Pete Cooper via llvm-dev wrote:
> Hey Lang
>> On Aug 18, 2015, at 6:04 PM, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi All,
>>
>> I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics.
>>
>>
>> (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy