search for: semanticless

...he user of such a pass is responsible for not applying this pass before any optimizations that might alter the representation of a pointer in an invalid manner. So specifically the proposal is just the following 1) Add llvm.experimental.gc.inttoptr and llvm.experimental.gc.ptrtoint as opaque "semanticless" intrinsic calls. They will be defined as `IntrNoMem` operations since they won't ever be lowered to anything that may perform any memory operations. 2) Add a pass LowerOpaqueIntergalPointerOps to perform the specified lowering in order to allow these intrinsics to be compiled to code. Us...

...t applying this pass before any optimizations that might >> alter the representation of a pointer in an invalid manner. >> >> So specifically the proposal is just the following >> 1) Add llvm.experimental.gc.inttoptr and llvm.experimental.gc.ptrtoint as >> opaque "semanticless" intrinsic calls. They will be defined as `IntrNoMem` >> operations since they won't ever be lowered to anything that may perform >> any memory operations. >> >> 2) Add a pass LowerOpaqueIntergalPointerOps to perform the specified >> lowering in order to allow...

...mption? Why wouldn't the default (no explicit) calling convention do for a storage-only format like SPIR? When it does come to codegen (for a CPU target), an LLVM backend would be forced to change the calling convention back to something standard anyway. So what's the advantage of adding a semanticless calling convention over metadata? >> (b) Why disallow type conversion for vector types? (ss. 3.3) > [Villmow, Micah] Type conversions in OpenCL between vector types is doing > via builtin functions and not via implicit conversions, so there is no OpenCL > code that can generate thes...

...ample varargs is illegal except for printf, kernels and functions are different, etc...). > > When it does come to codegen (for a CPU target), an LLVM backend would > be forced to change the calling convention back to something standard > anyway. So what's the advantage of adding a semanticless calling > convention over metadata? [Villmow, Micah] I wouldn't say it is semantic-less, just that its semantics are different than the calling conventions that LLVM currently supports. > > >> (b) Why disallow type conversion for vector types? (ss. 3.3) > > [Villmow, Micah...

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, September 11, 2012 8:49 AM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR provisional specifciation is now available > in the Khronos website > > Hi Boaz, >

...s illegal except for printf, kernels and functions are different, etc...). >> >> When it does come to codegen (for a CPU target), an LLVM backend would >> be forced to change the calling convention back to something standard >> anyway. So what's the advantage of adding a semanticless calling >> convention over metadata? > [Villmow, Micah] I wouldn't say it is semantic-less, just that its semantics are different than the calling conventions that LLVM currently supports. >> >> >> (b) Why disallow type conversion for vector types? (ss. 3.3) >>...

...s illegal except for printf, kernels and functions are different, etc...). >> >> When it does come to codegen (for a CPU target), an LLVM backend would >> be forced to change the calling convention back to something standard >> anyway. So what's the advantage of adding a semanticless calling >> convention over metadata? > [Villmow, Micah] I wouldn't say it is semantic-less, just that its semantics are different than the calling conventions that LLVM currently supports. >> >> >> (b) Why disallow type conversion for vector types? (ss. 3.3) >>...

...for printf, kernels and functions are different, etc...). >>> >>> When it does come to codegen (for a CPU target), an LLVM backend would >>> be forced to change the calling convention back to something standard >>> anyway. So what's the advantage of adding a semanticless calling >>> convention over metadata? >> [Villmow, Micah] I wouldn't say it is semantic-less, just that its semantics are different than the calling conventions that LLVM currently supports. >>> >>> >> (b) Why disallow type conversion for vector types? (ss...

...are different, > etc...). > >>> > >>> When it does come to codegen (for a CPU target), an LLVM backend > would > >>> be forced to change the calling convention back to something > standard > >>> anyway. So what's the advantage of adding a semanticless calling > >>> convention over metadata? > >> [Villmow, Micah] I wouldn't say it is semantic-less, just that its > semantics are different than the calling conventions that LLVM > currently supports. > >>> > >>> >> (b) Why disallow type co...