similar to: [LLVMdev] Semantics of noalias with vector of pointers?

Do you actually have a use case for such attributes, or are you just trying all possible attributes on all possible types to see what breaks? ;-) It would be theoretically possible to define semantics for signext/zerext or even noalias for vectors. However it's not clear whether those are really desirable without motivating use cases. Dan On Wed, Sep 4, 2013 at 2:31 PM, Matt Arsenault

Hi Duncan, thanks for the hint. I tried both variants: define <4 x float> @masked_add_1(<4 x i1> signext %mask, <4 x float> %a, <4 x float> %b) define <4 x float> @masked_add_32(<4 x i32> %mask, <4 x float> %a, <4 x float> %b) Unfortunately, this will raise an assertion: Wrong types for attribute: zeroext signext noalias nocapture sret byval nest

Hi Roland, > define <4 x float> @masked_add_1(<4 x i1> %mask, <4 x float> %a, <4 x float> %b) { > entry: > %add = fadd <4 x float> %a, %b > %sel = select <4 x i1> %mask, <4 x float> %add, <4 x float> %a > ret <4 x float> %sel > } > > I will get: > > addps %xmm1, %xmm2 > pslld $31, %xmm0 >

Hi all, I'm currently trying to figure out the best way to pass vector of booleans to other functions. Take this small example: define <4 x float> @vcmp_add(<4 x float> %a, <4 x float> %b) { entry: %cmp = fcmp olt <4 x float> %a, %b %add = fadd <4 x float> %a, %b %sel = select <4 x i1> %cmp, <4 x float> %add, <4 x float> %a ret <4 x

Since Rust references usually never aliases it would be nice if we could exploit this for code generation. One idea I had to improve alias analysis is to insert metadata on pointer loads. !inheritalias could be added to load instructions to indicate that if we know all the aliases of the pointer we load from, then we also know all the aliases of the pointer value loaded. Given that pointer loads

So, I'm not really sure if this is the right approach. I'd like some folks from the LLVM side of things to chime in. In general, I'm not certain we want to continue growing our dependence on the signext and zeroext attributes on return types, or whether we want to do the extension in the frontend instead. Most of the targets in Clang currently eagerly zext or sext the return value to

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

----- Original Message ----- > Hi Matt, > > On Nov 8, 2013, at 1:14 PM, Matt Arsenault > <Matthew.Arsenault at amd.com> wrote: > > > Both of these I think sort of went in the wrong direction and > > talked specifically about the semantics of the atomic instructions > > (fence in particular), which isn't the real question. Is noalias > > supposed

Hi Matt, On Nov 8, 2013, at 1:14 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > Both of these I think sort of went in the wrong direction and talked specifically about the semantics of the atomic instructions (fence in particular), which isn't the real question. Is noalias supposed to mean that no other thread can also have a copy of the pointer it also modifies? My

On 12/04/2013 04:29 PM, Andrew Trick wrote: > On Dec 4, 2013, at 3:33 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > >> On 11/11/2013 03:13 PM, Andrew Trick wrote: >>> On Nov 9, 2013, at 1:39 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: >>> >>>> On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote:

Hi, For a long time we've been having a problem we've been working around in OpenCL where loads are moving across an intrinsic used for a barrier. Attached is the testcase, and the result of opt -S -basicaa -gvn on it. This example is essentially this: void foo(global float2* result, local float2* restrict data0, ...) { int id = get_local_id(0); // ... data0[id] = ...;

On 11/11/2013 03:13 PM, Andrew Trick wrote: > On Nov 9, 2013, at 1:39 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > >> On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote: >> >>> Perhaps you're instead trying to say that with certain address spaces "noalias" (and by inference, "restrict" at the language

On Dec 4, 2013, at 5:19 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 12/04/2013 04:29 PM, Andrew Trick wrote: >> On Dec 4, 2013, at 3:33 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: >> >>> On 11/11/2013 03:13 PM, Andrew Trick wrote: >>>> On Nov 9, 2013, at 1:39 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:

On Nov 8, 2013, at 1:53 PM, Owen Anderson <resistor at mac.com> wrote: > Hi Matt, > > On Nov 8, 2013, at 1:14 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > >> Both of these I think sort of went in the wrong direction and talked specifically about the semantics of the atomic instructions (fence in particular), which isn't the real question. Is

On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote: > > Perhaps you're instead trying to say that with certain address spaces "noalias" (and by inference, "restrict" at the language level) has a different semantic model than other address spaces? While it's less worrisome than the first interpretation, I still don't really

Hi, I am trying to understand what is or what should be the correct semantic of the function parameter attribute noalias. I found: http://zion.cs.uiuc.edu/bugs/show_bug.cgi?id=1373 and http://www.llvm.org/docs/LangRef.html#paramattrs from the first link: "The semantics of 'noalias' are that they "define a new object". Any pointer derived from it ("it" being

Using LLVM ToT and Hal's helpful slide deck [1], I've been trying to use `llvm.assume` to communicate pointer alignment guarantees to vector load and store instructions. For example, in [2] %5 and %9 are guaranteed to be 32-byte aligned. However, if I run this IR through `opt -O3 -datalayout -S`, the vectorized loads and stores are still 1-byte aligned [3]. What's going wrong? Do I

Hi, I'm not sure what the expected behavior of calling a bitcasted function is. Suppose you have a case like this (which you get on the source level from attribute alias): @alias_f32 = alias bitcast (i32 (i32)* @func_i32 to float (float)*) define internal i32 @func_i32(i32 %v) noinline nounwind { entry: ret i32 %v } define void @bitcast_alias_scalar(float* noalias %source, float* noalias

Sent from my iPhone > On Nov 8, 2013, at 6:32 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> Hi Matt, >> >> On Nov 8, 2013, at 1:14 PM, Matt Arsenault >> <Matthew.Arsenault at amd.com> wrote: >> >>> Both of these I think sort of went in the wrong direction and >>> talked specifically about the

Hi, > What we are trying to do is to add new attributes (more maybe added > later): > > > sign_ext_from_i8, sign_ext_from_i16 > > zero_ext_from_i8, zero_ext_from_i16 > > to function definition so (assuming that both caller and callee are > generated in the same front-end) the caller will know if the callee has > already extended the return value or not, then