search for: addresspac

...quot;). Er, not sure what you're getting at. The value type has to match the pointee type of the address type. If we can't have a value type which is a struct, how'd we end up with a struct typed pointer? > > And since the backend only distinguishes pointer types based on > addresspace, pNi8 seems sufficient, no? > > -Ahmed

On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote: > On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > In the current mangling scheme for overloaded intrinsics we include > > overloaded type names in the intrinsic name. For example: > > > > %struct.foobar =

On 08/26/2015 07:02 PM, Chandler Carruth wrote: > On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Currently, the alloca instruction always allocates in the generic > address space (0). > > This proposal is to extend the semantics of alloca instruction to >

...e from the Module's datalayout. > > Ok. Is datalayout normally supposed to be used to convey IR lowering semantics? Or should it be immutable per target? > > During statepoint lowering, I guess the IR does not change in any locally recognizable way. Pointer types are all still addresspace(1) right? Changing the datalayout to change the meaning of those types makes sense to me if it’s ok with everyone else. I see what you're getting at here -- changing the datalayout does seem a little hacky. Maybe there is an efficient way to remap types (without deleting and re-creating ev...

This is a proposal to add strong GC reference types to LLVM. We have some local (downstream) patches that are needed to prevent LLVM's optimizer from making transforms that are problematic in the presence of a precise relocating GC. Adding a notion of a strong GC reference to LLVM will let us upstream these patches in a principled manner, and will act as a measure to avoid new problematic