Displaying 20 results from an estimated 26 matches for "dbginfointrinsics".
Did you mean:
dbginfointrinsic
2017 Nov 22
2
Retrieving DbgInfoIntrinsics for a given value
Hi LLVM,
If I have an llvm value "<16 x float> addrspace(1)* %in", and in the LLVM
IR, there is a @llvm.dbg.value like:
call void @llvm.dbg.value(metadata <16 x float> addrspace(1)* %in, i64 0,
metadata !216, metadata !28), !dbg !217
How I can retrieve this @llvm.dbg.value when I have "%in"?
Since Metadata is not a part of the uselist anymore, is there some way
2006 Apr 07
3
[LLVMdev] CVS Broken?
I just updated from CVS, and after doing a clean rebuild I get this
error:
/Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In
static member function 'static bool llvm::DbgInfoIntrinsic::classof
(const llvm::IntrinsicInst*)':
/Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:77:
error: 'dbg_declare' is not a member of 'llvm::Intrinsic'
2012 Feb 03
1
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>:
> Hi,
>
> I've tracked the first problem (mentioned in my previous email, quoted
> below) down further, ending up in the handling of alloca in
> LoopRotation.cpp (from trunk):
>
> // If the instruction's operands are invariant and it doesn't read
> or write
> // memory, then it is
2006 Apr 07
0
[LLVMdev] CVS Broken?
On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote:
> I just updated from CVS, and after doing a clean rebuild I get this error:
Are you sure that no conflicts prevented updating from going smoothly? How
are you building (srcdir ==/!= objdir)?
-Chris
> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static
> member function 'static bool
2009 Aug 22
2
[LLVMdev] PR4174
On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote:
> On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org>
> wrote:
>>
>> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote:
>>
>>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org>
>>> wrote:
>>>>
>>>> On Aug 21, 2009, at 8:46 PM, Eli
2006 Apr 07
2
[LLVMdev] CVS Broken?
I did a utils/cvsupdate, and there are no conflicts. srcdir !=
objdir. This is on persephone.
Are you not getting this error? Perhaps I should check out a fresh
tree and try to compile it?
Rob
On Apr 7, 2006, at 11:40 AM, Chris Lattner wrote:
> On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote:
>> I just updated from CVS, and after doing a clean rebuild I get
>> this
2009 Aug 22
0
[LLVMdev] PR4174
On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote:
>
> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote:
>
>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote:
>>>
>>> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote:
>>>
>>>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at
2009 Nov 04
0
[LLVMdev] Debug Information for LLVM 2.6 and TOT
...ion when such information interferes with
> optimization. Is this correct,
Yes.
> and if so, does anyone know off-hand
> which optimizations do this?
The optimizer does not emit any statistics here. You can search
various transformation passes' code to see whether they are handling
DbgInfoIntrinsics or not. Or may be I misunderstood your question ?
> 2) I believe a new debug annotation design is being implemented in
> mainline LLVM for the 2.7 release. What is the current status of this
> work? Does it already yield more accurate debug information than LLVM 2.6?
It is still a work...
2009 Nov 04
2
[LLVMdev] Debug Information for LLVM 2.6 and TOT
Dear All,
1) I recall reading somewhere that a few optimizations in LLVM 2.6 strip
away debug information when such information interferes with
optimization. Is this correct, and if so, does anyone know off-hand
which optimizations do this?
2) I believe a new debug annotation design is being implemented in
mainline LLVM for the 2.7 release. What is the current status of this
work? Does
2009 Aug 22
0
[LLVMdev] PR4174
On Fri, Aug 21, 2009 at 5:47 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote:
>
> On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote:
>
>> On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote:
>>>
>>> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote:
>>>
>>>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at
2006 Apr 07
2
[LLVMdev] CVS Broken?
I've done several CVS head builds today .. no problems on Linux.
Reid.
On Fri, 2006-04-07 at 11:53 -0500, Chris Lattner wrote:
> On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote:
>
> > I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This
> > is on persephone.
> >
> > Are you not getting this error? Perhaps I should check out a fresh
2006 Apr 07
0
[LLVMdev] CVS Broken?
On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote:
> I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This
> is on persephone.
>
> Are you not getting this error? Perhaps I should check out a fresh tree and
> try to compile it?
Nope, I don't think anyone else is getting this error. If you could try a
fresh build that would be great, I'll fire
2009 Aug 22
2
[LLVMdev] PR4174
On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote:
> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org>
> wrote:
>>
>> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote:
>>
>>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org>
>>> wrote:
>>>>
>>>> On Aug 21, 2009, at 7:31 PM, Eli
2012 Feb 03
0
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
Hi,
I've tracked the first problem (mentioned in my previous email, quoted
below) down further, ending up in the handling of alloca in
LoopRotation.cpp (from trunk):
// If the instruction's operands are invariant and it doesn't read
or write
// memory, then it is safe to hoist. Doing this doesn't change the
order of
// execution in the preheader, but does
2006 Apr 07
0
[LLVMdev] CVS Broken?
I'm guessing the problem occurred because I hadn't updated in a while
(maybe a couple of weeks?) and I had an old Intrinsics.gen file
hanging around in my source directory that was getting picked up by
the makefile for some reason. This is a bug, but maybe it's harmless
because there's a onetime workaround (delete the file by hand) and it
won't be a problem for
2012 Feb 01
3
[LLVMdev] Issues with the llvm.stackrestore intrinsic
Hi,
I have two problems regarding the llvm.stackrestore intrinsic. I'm
running on 3.0, but a quick test on trunk also showed the same behavior.
First problem:
---------------
I have code like:
tmp1 = call llvm.stacksave()
tmp2 = alloca
[do some stuff with tmp2]
call llvm.stackrestore(tmp1)
[some other stuff]
tmp3 = call llvm.stacksave()
tmp4 = alloca
[do some stuff
2012 Mar 28
1
[LLVMdev] Removing Intrinsic Functions
There are a few instrinsic functions I would like to remove, is this
possible? For example, the llvm.lifetime and llvm.dbg instrinsics?
You can't simply iterate over the funciton and remove the call
instructions, this causes issues. Is there a known structured way of doing
this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2006 Apr 07
2
[LLVMdev] CVS Broken?
OK, when I copy $(SRCDIR)/include/llvm/Intrinsics.gen to $(OBJDIR)/
include/llvm/ by hand after building (and failing) once, the build
succeeds. This is definitely a makefile bug.
Rob
On Apr 7, 2006, at 11:40 AM, Chris Lattner wrote:
> On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote:
>> I just updated from CVS, and after doing a clean rebuild I get
>> this error:
>
>
2010 Nov 24
2
[LLVMdev] how to eliminate dead infinite loops?
On 11/24/2010 03:36 PM, Nick Lewycky wrote:
> Andrew Clinton wrote:
>> Most of my programs contain loops that the LoopDeletion pass is unable
>> to remove. It appears that the following code in LoopDeletion.cpp:152
>> is the culprit:
>>
>> ScalarEvolution& SE = getAnalysis<ScalarEvolution>();
>> const SCEV *S =
2013 Nov 26
3
[LLVMdev] Finding the first line number of a function (-g vs -gline-tables-only)
For the sample profiler, I need to determine the location of the first
user instruction in the function. This can be the LOC where the
function header is or the LOC of the actual first instruction, it
doesn't really matter. But it needs to be consistent wrt -g and
-gline-tables-only.
Currently, I'm scanning for the first non-zero line number from the
top of the function. This skips over