Displaying 20 results from an estimated 1200 matches similar to: "[LLVMdev] First-class debug info IR: MDLocation"
2014 Oct 27
2
[LLVMdev] First-class debug info IR: MDLocation
> On 2014-Oct-27, at 00:58, Chandler Carruth <chandlerc at google.com> wrote:
>
> I haven't been able to follow all of the thread that got us here but your patch below has distilled the result enough for me to at least ask questions.
Always takes a patch to draw people in :).
> I'm sorry of some of the justification is buried in the thread and I'm just making you
2015 Jan 13
3
[LLVMdev] [RFC] First-class debug info IR: MDLocation (redux)
After splitting `Metadata` apart from `Value`, I'm finally back to the
first step [1] of representing debug info more directly in IR [2]:
`MDLocation`.
[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078173.html
"First-class debug info IR: MDLocation"
[2]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html
"Less memory and greater
2015 Jan 13
2
[LLVMdev] [RFC] First-class debug info IR: MDLocation (redux)
I suspect it would actually be *better* if I got all this in before
the branch, since it'll make cherry-picking testcases easier.
However, these patches themselves (and I suspect a few more prep
commits) don't actually move `MDLocation` into place -- it's not
until then that all the testcase updates have to happen. I'm not
convinced that (monster) commit will land by tomorrow :(.
2015 Jan 13
2
[LLVMdev] [RFC] First-class debug info IR: MDLocation (redux)
Hi Paul,
I'm not sure I see any reason to wait until after 3.6. More changes are
incoming and it's better to get them over with sooner rather than spread
out the pain.
Thanks!
-eric
On Mon Jan 12 2015 at 9:52:48 PM Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:
> Would you mind terribly waiting a week, until after 3.6 is forked?
>
> We're barely
2015 Jan 14
3
[LLVMdev] Should I commit "IR: Move MDLocation into place" before or after 3.6 branch?
> On 2015-Jan-14, at 11:26, Adrian Prantl <aprantl at apple.com> wrote:
>
>
>> On Jan 14, 2015, at 11:12 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>>
>> On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote:
>> One small request: Omitting the column field from MDLocation if it is 0 is fine,
2015 Jan 15
2
[LLVMdev] [RFC] First-class debug info IR: MDLocation (redux)
> On 2015 Jan 13, at 11:13, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
>
>> I suspect it would actually be *better* if I got all this in before
>> the branch, since it'll make cherry-picking testcases easier.
>
> Excellent point, go for it.
I missed the branch deadline, but I merged it in as of r226095.
> --paulr
>
>>
>>
2015 Jan 14
3
[LLVMdev] Should I commit "IR: Move MDLocation into place" before or after 3.6 branch?
On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote:
> One small request: Omitting the column field from MDLocation if it is 0 is
> fine, because it won’t make it into the line table. Omitting the line if it
> is 0 is not, because it gives the wrong impression that the line is being
> ignored, which is not the case. Line 0 will be emitted in the line
2014 Oct 13
9
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
In r219010, I merged integer and string fields into a single header
field. By reducing the number of metadata operands used in debug info,
this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling
of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and
I've concluded that they will be insufficient.
Instead, I'd like to implement a more aggressive plan,
2014 Oct 16
2
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
On Wed, Oct 15, 2014 at 8:53 PM, Alex Rosenberg <alexr at leftfield.org> wrote:
> As all of these transforms are 1-to-1, can we still support the older metadata and convert it on the fly?
>
I'd prefer not to keep all of that code around to interpret both
versions without a very good reason.
-eric
> Alex
>
>> On Oct 13, 2014, at 3:02 PM, Duncan P. N. Exon Smith
2014 Oct 15
3
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
On Mon, Oct 13, 2014 at 7:01 PM, Eric Christopher <echristo at gmail.com>
wrote:
> On Mon, Oct 13, 2014 at 6:59 PM, Sean Silva <chisophugis at gmail.com> wrote:
> > For those interested, I've attached some pie charts based on Duncan's
> data
> > in one of the other posts; successive slides break down the usage
> > increasingly finely. To my
2014 Oct 14
2
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
For those interested, I've attached some pie charts based on Duncan's data
in one of the other posts; successive slides break down the usage
increasingly finely. To my understanding, they represent the number of
Value's (and subclasses) allocated.
On Mon, Oct 13, 2014 at 3:02 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
> In r219010, I merged integer and
2015 Apr 29
2
[LLVMdev] Assertion failure (Bug 21609) in DwarfFile.cpp
Hi Folks,
I ran into this assertion failure while compiling a function with a
large number of arguments:
https://llvm.org/bugs/show_bug.cgi?id=21609
I have coded up the fix as per David's suggestion (added a new header
field for DIVariable to separate out ArgNo & LineNo). The proposed
diff is attached to the bug.
However, there are around 175 testcases across clang & llvm that need
2020 May 31
2
LLC crash while handling DEBUG info
Hi-
Here is the simple C++ function:
-----------
void foo() {
}
-----------
Let's say, above function is compiled to generate LLVM IR with -g flag
using the command line `clang++ -g -O0 -S -emit-llvm foo.cpp`, we get
below IR
-----------
; ModuleID = 'foo.cpp'
source_filename = "foo.cpp"
target datalayout =
2017 Nov 15
2
workaround for debug info bug?
I just reported this bug:
https://bugs.llvm.org/show_bug.cgi?id=35314
This very simple IR is causing infinite recursion
in llvm::DwarfUnit::getOrCreateTypeDIE in llvm 5.0.0.
Is there a workaround? Is anyone willing to save me a recompile and check
if this is fixed in 5.0.1 or trunk?
`clang -c test.ll` repros the issue.
; ModuleID = 'test'
source_filename = "test"
target
2015 Apr 29
2
[LLVMdev] Assertion failure (Bug 21609) in DwarfFile.cpp
On Tue, Apr 28, 2015 at 7:14 PM, David Blaikie <dblaikie at gmail.com> wrote:
> I believe duncan's fixed this recently in 235956 and 235955 - does ToT work
> for you?
It seems like r235955 might have fixed it. However I'm having build
issues with ToT in my environment. Is this the right place to check
ToT build status:
http://lab.llvm.org:8011/one_line_per_build
>
> On
2020 May 31
2
LLC crash while handling DEBUG info
Hi David
If you look at line
https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160
there is IR verification which asserts that only in case of `spFlags
= DISPFlagDefinition`, the compilation unit (`unit` field) should be
present. Otherwise, it should *not* be present. In the crash case,
`spFlags = DISPFlagOptimized`. So, I guess, `unit` field should *not* be
present,
2015 Jan 19
6
[LLVMdev] [3.6 Release] RC1 has been tagged, Testing Phase I begins
On 15 January 2015 at 13:35, Renato Golin <renato.golin at linaro.org> wrote:
> AArch64 tested and uploaded. ARMv7 in progress.
Hi Hans,
ARMv7 is giving me a bit of a headache... I've tried building on two
different machines and I get the same error... Phase 2 completes
successfully, but while building Phase 3, I get the error on *every*
file:
1.
2020 May 31
2
LLC crash while handling DEBUG info
I am bit confused - `unit` must be present for definitions, and `optimized `
is also a `definition`, so, `unit` must be present for `optimized ` too. Am
I right?
Mahesha
On Sun, May 31, 2020 at 10:14 PM David Blaikie <dblaikie at gmail.com> wrote:
> definition and optimized are orthogonal (a function could be both, or
> neither) - one says this DISubprogram describes a function
2017 Oct 01
2
load with alignment of 1 crashes from being unaligned
Below is attached a full IR module that can reproduce this issue, but the
part to notice is this:
%Foo96Bits = type <{ i24, i24, i24, i24 }>
define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 {
Entry:
%value = alloca %Foo96Bits, align 1
%b = alloca i24, align 4
%0 = bitcast %Foo96Bits* %value to i8*, !dbg !129
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast
2017 Jun 19
2
LLVM behavior different depending on function symbol name
On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
> Hi,
>
> 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> Greetings,
>>
>> I have a Zig implementation of ceil which is emitted into LLVM IR like
>> this:
>>
>> ; Function Attrs: nobuiltin nounwind
>> define