similar to: [LLVMdev] LangRef

The page looks ok to me... You are talking about this page, right? http://llvm.org/docs/LangRef.html -Tanya On Tue, 10 Jun 2008, David Greene wrote: > The LangRef page is missing a bunch of stuff, including documentation > for all the LLVM instructions. > > The page ruins dorectory from Vector Types to llvm.readcyclecounter. > Everything in-between is missing. > >

Hi Hal, Thanks for the pointer. Is it possible to get the processor ID on X86 architecture? There is a library call in linux, sched_getcpu(), to the ID. Also, is it possible to get the program counter in the IR? Best, Zhi On Thu, Nov 19, 2015 at 1:33 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Zhi, > > There is no standard (architecture-independent) way to get the processor

> What's the API to retrieve current time of day in llc? > I need to use this to generate an unique number every time llc runs. The llvm.readcyclecounter might suit your needs: http://www.llvm.org/docs/LangRef.html#int_readcyclecounter Regards, -Mahadevan.

Say if we have 8 cores, I want to get which core is running the current program. Thanks. On Thu, Nov 19, 2015 at 3:37 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "zhi chen" <zchenhn at gmail.com> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: llvm-dev at lists.llvm.org > > Sent: Thursday,

I'v set the default_mail_env to maildir:/var/maildir/%d/%u where /var/maildir/ is the root dorectory for my maildir tree and I'm getting the folowing error in the maillog : Jan 3 15:16:58 websrv pop3(roi): unlink(/var/maildir//roi/cur/new:2,T) failed: Is a directory Notice that the %d is missing. If I change to 'default_mail_env = maildir:/var/maildir/example.tld/%u' then

What's the API to retrieve current time of day in llc? I need to use this to generate an unique number every time llc runs. TIA - Sanjiv

Hi, I am wondering if it is possible to get the time-stamp and the processor ID where an instruction is exectued in the IR? Thanks for your help in advance:) Best, Zhi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151119/dbbafb32/attachment.html>

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

On Tuesday 10 June 2008 13:45, Tanya M. Lattner wrote: > The page looks ok to me... > > You are talking about this page, right? > http://llvm.org/docs/LangRef.html Yeah. Hmm...Now it's ok for me. Strange. -Dave

The unbelivable Civilizations of the World<http://mega-structures.blogspot.com/2007/03/unbelivable-civilizations-of-world.html> The unbelivable Civilizations of the World <http://mega-structures.blogspot.com/> <http://mega-structures.blogspot.com/> ''Chaco Canyon Indian ruins, NM, circa 1060, The Center of ...<http://mega-structures.blogspot.com/>

Hi all, I've been discussing parameter attributes and their impact on first-class struct parameters. Duncan and I came to the conclusion that the only attribute that could be applied to structs currently, is the inreg attribute. However, since there is no support anywhere for that currently (transformation passes and backends?), it might be better to disallow the inreg attribute for struct

Hi all, due to the recent changes regarding paramater/function/return type attributes, I think the documentation around that could use some improvement. In particular, I see the following problems: * The section "Functions" in the LangRef has a large textual description about how it should look, but no definition of syntax, or even a few examples of the syntax. This makes it very

Hi, after working with llvm for a while, I'm still a little confused with the meaning of the 'byval' attribute. From the langref: "This indicates that the pointer parameter should really be passed by value to the function. The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee.

Hi, I'm trying to annotate certain functions in C code, and do something with these functions in my LLVM pass. I annotate the C code like this: int __attribute__((annotate("annot"))) function() { This nicely gets added to the LLVM bitcode in an @llvm.global.annotations global. Now I had hoped that it'd be easy to extract a list of functions annotated with my annotation

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for

Hi, I don't find DIGlobalVariableExpression in langref. Should it be documented? Could anybody explain what it is? https://llvm.org/docs/LangRef.html In one ll file converted from bitcode, I mostly see something like this. !8273 = !DIGlobalVariableExpression(var: !8274, expr: !DIExpression()) Only one looks like this. !8945 = !DIGlobalVariableExpression(var: !8946, expr:

Hi, So the Variable Argument Handling Intrinsics section of the LangRef (http://llvm.org/docs/LangRef.html#variable-argument-handling-intrinsics) lists an example that segfaults. Try the following on x86_64: -- 8< -- define i32 @test(i32 %X, ...) { ; Initialize variable argument processing %ap = alloca i8* %ap2 = bitcast i8** %ap to i8* call void @llvm.va_start(i8* %ap2) ; Read a

Hi Chris & Evan, On Sun, Jul 13, 2008 at 03:34:03PM -0700, Chris Lattner wrote: > Why? What value does that provide? Struct indices are not allowed to > be variable, so picking any width constant (that isn't too small) is > fine. What problem are you trying to solve here? The current code only allows 32 bit constants. My patch allows any width constant to be used, but it

Hi Devang, the improvements you made are good, I think the docs are a lot clearer now. I stil have a few more points, though. > > * The section "Functions" in the LangRef has a large textual description > > about how it should look, but no definition of syntax, or even a few > > examples of the syntax. This makes it very hard to read. > > This description

On 01/11/2010 11:20 AM, Jeffrey Yasskin wrote: > Awesome, thanks! Committed as r93170 with the following change: > > s/local variables/registers/. "Local variable" refers to allocas in > LLVM, rather than %whatever SSA "variables". Excellent. I was not actually happy with that term when I wrote it, but wasn't sure of the standard terminology. It should