search for: targetdescription

Hello, I am trying to find out where the complete documentation for the TargetDescription string documentation is. I am reading the tutorial and looking at the sparc backend at the same time and there are some discrepancies. Therefore the documentation would be extremely valuable but I can't seem to find it. In the tutorial it shows the string "E-p:32:32-f128:128:128", bu...

In "Writing an LLVM Compiler Backend", there's some discussion of the TargetDescription string, but it doesn't explain the examples I look at. For instance, in the description of the PowerPC, I see "E-p:64:64-f64:64:64-i64:64:64-f128:64:128-n32:64" What's "preferred alignment" versus "ABI alignment"? What are the 3 figures following the &qu...

Paulo J. Matos wrote: > Hello, > > I am trying to find out where the complete documentation for the > TargetDescription string documentation is. > I am reading the tutorial and looking at the sparc backend at the same > time and there are some discrepancies. Therefore the documentation > would be extremely valuable but I can't seem to find it. > > In the tutorial it shows the string "E-p:32:3...

On Thu, May 27, 2010 at 7:09 PM, John Criswell <criswell at uiuc.edu> wrote: > I believe what you want is documented here: > > http://llvm.org/docs/LangRef.html#datalayout > Just a note, since it might be a bug on the backend or documentation. It says on the documentation that size for f is either 32 or 64, however, sparc has 64 and 128. -- PMatos

On Thu, May 27, 2010 at 11:18 AM, Paulo J. Matos <pocmatos at gmail.com> wrote: > On Thu, May 27, 2010 at 7:09 PM, John Criswell <criswell at uiuc.edu> wrote: >> I believe what you want is documented here: >> >> http://llvm.org/docs/LangRef.html#datalayout >> > > Just a note, since it might be a bug on the backend or documentation. > It says on the

...and geps only), this is done. The TargetData part is a lot more tricky. I originally planned to simply add a virtual method to TargetData and create a specific subclass for our compiler, when I discovered that this is not how TargetData is supposed to work. Currently, TargetData consists only of a TargetDescription, which is basically only sizes and alignment info for different types. I solved this by creating a new class AddrspacesDescriptor, which has a single virtual method that defines the relationship between address spaces. This class contains a default implementation and can be subclassed to get a dif...

Hi I was wondering if within the TargetDescription string it was possible to specify different alignment for variables on stack versus globals. If not, is there any other way to specify that ? thanks shrey

...; The TargetData part is a lot more tricky. I originally planned to > simply add a > virtual method to TargetData and create a specific subclass for our > compiler, > when I discovered that this is not how TargetData is supposed to work. > Currently, TargetData consists only of a TargetDescription, which is > basically > only sizes and alignment info for different types. > > I solved this by creating a new class AddrspacesDescriptor, which > has a single > virtual method that defines the relationship between address spaces. > This > class contains a default impl...

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

...le class will be able to take any architecture-specific decision with just strings. Such arch-specific classes will, later, be built from a special table-gen back-end that will always be enabled for all targets, but that's much later. The final goal is to keep all that information into one big TargetDescription class, which will also help Clang and other users to know information about the targets, for instance, what combination of environment, ABI and CPU features, to take informed decisions without needing any back-end built in. Is that in line with your reasoning? cheers, --renato

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

...tializeAllTargetInfos; // initialize native target in particular LLVMInitializeNativeTarget; // get first target Target := LLVMGetFirstTarget; // loop until the target is NULL while (Target <> nil) do begin // get target name & description TargetName := LLVMGetTargetName(Target); TargetDescription := LLVMGetTargetDescription(Target); // do something with these information Target := LLVMGetNextTarget(Target); end; By debugging the LLVM library (a custom DLL, which works fine otherwise), I can see that there is no information, but I'm not that deep into C and the LLVM structure to i...

...any architecture-specific decision with just strings. > Such arch-specific classes will, later, be built from a special > table-gen back-end that will always be enabled for all targets, but > that's much later. > > The final goal is to keep all that information into one big > TargetDescription class, which will also help Clang and other users to > know information about the targets, for instance, what combination of > environment, ABI and CPU features, to take informed decisions without > needing any back-end built in. > > Is that in line with your reasoning? > > c...

Hello >   I was wondering if within the TargetDescription string it was > possible to specify different alignment for variables on stack versus > globals. If not, is there any other way to specify that ? You can always ensure necessary alignment for globals during asmprinting / codeemission. This is in fact done inside some backends... -- With bes...

...particular > LLVMInitializeNativeTarget; > > // get first target > Target := LLVMGetFirstTarget; > > // loop until the target is NULL > while (Target <> nil) do > begin > // get target name & description > TargetName := LLVMGetTargetName(Target); > TargetDescription := LLVMGetTargetDescription(Target); > > // do something with these information > > Target := LLVMGetNextTarget(Target); > end; > I don't see any obvious problems here, though someone else might. What exactly is the problem you are seeing? Is LLVMGetFirstTarget return...

...rget; >> >> // get first target >> Target := LLVMGetFirstTarget; >> >> // loop until the target is NULL >> while (Target <> nil) do >> begin >> // get target name & description >> TargetName := LLVMGetTargetName(Target); >> TargetDescription := LLVMGetTargetDescription(Target); >> >> // do something with these information >> >> Target := LLVMGetNextTarget(Target); >> end; >> > I don't see any obvious problems here, though someone else might. > What exactly is the problem you are seeing?...

...// Free TM delete TM; ==== END CODE SNIPPET ==== For your case, you should be able to find TripleStr and FeatureStr in somewhere. And also there's a constructor in TargetData ( http://llvm.org/doxygen/classllvm_1_1TargetData.html#a0d7acb06af9665b54fc74480e2c6c707) takeing a string "TargetDescription". The string specifies the data layout of a target and its format is described here http://llvm.org/docs/LangRef.html#datalayout. Thus, if you are developing a customized target and/or you are really know the data layout specification about your target, you can get a TargetData instance by sim...

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part

...better. Another example is assembler / linker flags (-Wa,-Wl), which are not supported at all for the integrated assembler and would be another user of parsing and inspecting capabilities. All the information is there, in the table-gen files, and could be easily accessed into an abstraction layer (TargetDescription or whatever), which TargetParser could use, as well as all other tools, including lld, lldb, etc. We're not talking about duplication, we're talking about multiplication by a factor a lot more than two. cheers, --renato

On 10 March 2015 at 16:20, Mehdi Amini <mehdi.amini at apple.com> wrote: > I’d like to avoid as much as possible adding compilation time to the process unless it is necessary (I’m not saying it does not worth it here). As I said in the review, it may end up being faster, because of the amount of crap we'll remove from all tools and LLVM. > It is not clear to me why do you need