search for: targetcodegeninfo

...ess spaces, and frontends should use a language -> target mapping in target-specific code. We can continue to expose the target's main shared writable address space as address space 0 as we do now. For example, Clang could define a set of internal address space constants for OpenCL and use TargetCodeGenInfo to provide the mapping to target address spaces. An additional benefit is that this solution would allow AMD and other backends with non-standard orderings [1] to retain backward compatibility. In Clang, by default, pointers would be in language address space 0, which could map to any target addr...

...return ABIArgInfo::getIndirect(0); return ABIArgInfo::getDirect(); } ABIArgInfo MSP430ABIInfo::classifyArgumentType(QualType Ty) const { if (isAggregateTypeForABI(Ty)) return ABIArgInfo::getIndirect(0); return ABIArgInfo::getDirect(); } 3) Register your new MSP430ABIInfo class in the TargetCodeGenInfo constructor inside MSP430TargetCodeGenInfo by replacing DefaultABIInfo. Hope this helps. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121008/a1ec7539/attachment.html>

...s should use a language -> target mapping > in target-specific code.  We can continue to expose the target's main > shared writable address space as address space 0 as we do now. > > For example, Clang could define a set of internal address space > constants for OpenCL and use TargetCodeGenInfo to provide the mapping > to target address spaces. In principle this is a fine idea. I think the difficulty is that LLVM and Clang provide an infrastructure for numbered address spaces, but no standard assignment on top of that infrastructure. The trick is define some conventions, e.g. what t...

On Thu, Feb 24, 2011 at 1:14 PM, Anton Lokhmotov <Anton.Lokhmotov at arm.com> wrote: > Hi Peter, > > Many thanks for your prompt review. > >> I don't think we should include the word OpenCL in the name of this >> enum/header.  We may very well in the future want to define address >> space constants for other languages, which should not overlap with >>

...age -> target mapping >> in target-specific code.  We can continue to expose the target's main >> shared writable address space as address space 0 as we do now. >> >> For example, Clang could define a set of internal address space >> constants for OpenCL and use TargetCodeGenInfo to provide the mapping >> to target address spaces. > > In principle this is a fine idea. > > I think the difficulty is that LLVM and Clang provide an > infrastructure for numbered address spaces, but no standard assignment > on top of that infrastructure. You can trace bac...

> -----Original Message----- > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > Sent: 04 January 2011 21:42 > To: Anton Lokhmotov > Cc: cfe-dev at cs.uiuc.edu > Subject: Re: OpenCL support > > Here are my comments on the second patch. > > > +enum OpenCLAddressSpace { > > + OPENCL_PRIVATE = 0, > > + OPENCL_GLOBAL = 1, > > + OPENCL_LOCAL