similar to: llvm::UpgradeDebugInfo does a full verification

Op 24-1-2018 om 18:26 schreef Adrian Prantl: > > >> On Jan 23, 2018, at 11:01 PM, Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I noticed that since recently UpgradeDebugInfo (Which is called for loading any bitcode from disk/memory) does a full bitcode verification. Is this on purpose or is this a mistake? Seems to have a

> On Jan 23, 2018, at 11:01 PM, Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I noticed that since recently UpgradeDebugInfo (Which is called for loading any bitcode from disk/memory) does a full bitcode verification. Is this on purpose or is this a mistake? Seems to have a fair amount of overhead. That is be design, though there are bugs in the LTO

> On Jan 24, 2018, at 10:47 PM, Carlo Kok <ck at remobjects.com> wrote: > > > > Op 24-1-2018 om 18:26 schreef Adrian Prantl: >>> On Jan 23, 2018, at 11:01 PM, Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi, >>> >>> I noticed that since recently UpgradeDebugInfo (Which is called for loading any

On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at

On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:26 AM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at

On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >> >> >> >> On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >>> >>> >>> >>> >>> On Thu,

On Fri, Nov 22, 2013 at 9:54 AM, Eric Christopher <echristo at gmail.com>wrote: > On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> > wrote: > >> > >> > >> > >> > >> On Thu, Nov 21, 2013 at

I think probably the simplest answer is that dbg.declare documents that it must point to an alloca ("This intrinsic provides information about a local element (e.g., variable). The first argument is metadata holding the alloca for the variable. ") - so it's probably best not to think too hard about what it does when that criteria is not met.

Hi all, Sometimes llvm::UpgradeDebugInfo <http://llvm.org/docs/doxygen/html/namespacellvm.html#ad3c29183c5faa7f5a352807af8aca268> drops debug info which is pretty compatible with recent llvm version ( http://stackoverflow.com/questions/27023713/missing-debug-metadata-in-llvm-after-xcode-update ) and sometimes it drops something really outdated, but acceptable for me. In both cases I want to

On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 11:26 AM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:06 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at

r287955 seems like it might be related. -- Sean Silva On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > This sounds buggy to me. What pass is doing this? > > -- Sean Silva > > On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> I've got some calls like: >>

Sorry, I was thinking to review the test but didn't. Is this test complete? It does invoke lld, but it didn't verify its output. On Mon, Jul 30, 2018 at 2:03 PM Andrew Kelley <superjoe30 at gmail.com> wrote: > Ping Rui. Is there anything else that needs to be done on this patch? > > On Tue, Jul 17, 2018 at 6:58 AM, Carlo Kok via llvm-dev < > llvm-dev at

I've got some calls like: musttail call void bitcast (i32 (i32, i8*, %Type*)* @MyMethod to void (i32, i8*)*)(i32 %0, i8* %1) ret void Into something like: %8 = tail call i32 @MyMethod(i32 %0, i8* %1, %Type* null) ret void I realize I'm losing a parameter there, but this is an interface jump trick I use and relies on the end code being a 'jmp' (x86). I realize i can probably

When linking a project with lld, the android libc links to __executable_start which isn't defined when linking with lld (tried on x86), but is when linking with gnu ld it seems. I tried: .globl __executable_start __executable_start = __ehdr_start as a workaround but seems to be ignored. Anyone know a better workaround? Thanks, -- Carlo Kok RemObjects Software

It's a wasm testcase that ends up with a 1 mb executable; after 15 minutes I killed it, it doesn't do anything (note that it's waiting on a conditional variable in ALL threads) On Wed, May 8, 2019, at 14:32, Brian Cain wrote: > Are you sure it's not just taking "a long time"? If that build machine doesn't have enormous amounts of memory you could end up with a

On Fri, Nov 22, 2013 at 10:14 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Fri, Nov 22, 2013 at 9:54 AM, Eric Christopher <echristo at gmail.com> > wrote: >> >> On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: >> > >> > >> > >> > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren

The problem is a bitcode implementation that has a stdcall function that's used from native code. 1 side has _elements_exception_handler, compiled that would be __elements_exception_handler at 20 due to stdcall. The native bit has the mangled name and the linker can't find it as the bitcode indexes have it without mangling. I'll try to prepare a testcase when I get back in the office.

On 2016-12-22 19:02, David Blaikie wrote: > if you could simplify it down a bit, that might be helpful - not sure > there's a lot to be gained - I imagine it is just a quirk of how we > handle these things in the backend to make normal debug info work, but > there might be some things to be done to help. > That's my guess too, special behavior when it sees an alloca.

When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all over the place: ... 0x00000000000595ac 22 11 1 0 0 is_stmt 0x00000000000595bc 25 7 1 0 0 is_stmt <<< 0x00000000000595c0 22 11 1 0 0 is_stmt 0x00000000000595c4 25 7 1 0 0 is_stmt <<< 0x00000000000595c8 26 7 1 0 0 is_stmt but the code only has 1 reference to line 25 and the

Mixing native and bitcode files should just work, and that happens all the time, as most programs need at least crt.o (which is a precompiled native object file containing startup code). Could you elaborate the issue a bit? It might be a bug in lld. On Fri, Mar 30, 2018 at 3:11 AM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Mar 30, 2018, at 11:23, Carlo Kok