search for: funcid

...ts to the same loopid (the self-referencing id metadata from the llvm.loop.parallel patch), check their iteration identifier, and if it's different, return NO ALIAS. The similar idea could be applied to preserve the 'restrict' info across function inlines: llvm.mem.restricted_access [funcid] [pointerid] Similarly, if the RestrictedPointerAA finds that both of the accesses are marked with this metadata and point to the same funcid, and the [pointerid] is different, it can return NO ALIAS. -- Pekka

...4193 I then attempt to use the xray-account utility to analyse the log but whilst the functions are named, the locations of the functions are displayed as <invalid>:0:0:. > llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm xray-log.llvm.hgD9oi Functions with latencies: 5 funcid count [ min, med, 90p, 99p, max] sum function 6 9 [ 0.000006, 0.000006, 0.000040, 0.000040, 0.000040] 0.000089 <invalid>:0:0: fqux ... 4 lines omitted If I then inspect the executable with llvm-dwarfdump, I can see that the debug info...

...llvm.loop.parallel patch), check their iteration identifier, and if > it's > different, return NO ALIAS. This also makes sense. > > The similar idea could be applied to preserve the 'restrict' info > across > function inlines: > > llvm.mem.restricted_access [funcid] [pointerid] > > Similarly, if the RestrictedPointerAA finds that both of the accesses > are > marked with this metadata and point to the same funcid, and the > [pointerid] > is different, it can return NO ALIAS. Interesting idea. I had worked out a proposal for more-general res...

...se the log but >> whilst the functions are named, the locations of the functions are >> displayed as <invalid>:0:0:. >> >>> llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm xray-log.llvm.hgD9oi >> >> Functions with latencies: 5 >> funcid count [ min, med, 90p, 99p, >> max] sum function >> 6 9 [ 0.000006, 0.000006, 0.000040, 0.000040, >> 0.000040] 0.000089 <invalid>:0:0: fqux >> ... 4 lines omitted >> >> If I then inspect the executabl...

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Tobias Grosser" <tobias at grosser.es> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Sunday, February 17, 2013 2:32:25 PM > Subject: Re: [LLVMdev] Parallel Loop Metadata > > > > > > On Feb 11, 2013, at 2:58 PM,

On Feb 11, 2013, at 2:58 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 02/11/2013 10:31 PM, Nadav Rotem wrote: >> Now that we have a better understanding of the proposal for using per-instruction metadata, I think that we need to revisit the "single metedata" approach (Pekka's original suggestion). > > Following Andrew's comments we understood that

...ed, the locations of the functions are >> >> displayed as <invalid>:0:0:. >> >> >> >>> llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm xray-log.llvm.hgD9oi >> >> >> >> Functions with latencies: 5 >> >> funcid count [ min, med, 90p, 99p, >> >> max] sum function >> >> 6 9 [ 0.000006, 0.000006, 0.000040, 0.000040, >> >> 0.000040] 0.000089 <invalid>:0:0: fqux >> >> ... 4 lines omitted >> >&...