similar to: this ir code segfaults llvm in trunk

So, 90% of the time I've seen this, it was memory corruption, usually use after free. I know I fixed one after 5.0 branched. You should compile with address sanitizer enabled, and I suspect you will find the issue quicky. If not, we really need ir that reproduces it. On Sun, Sep 17, 2017, 12:27 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think I forgot to

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

Hi all, I'm interested in fixing PR14481 (http://llvm.org/PR14481), regarding teaching LLVM that coldcc functions do not clobber any registers. As a brief motivation why: this can have a significant performance benefits and is very useful for instrumenting code with many calls that are executed only very rarely. Ubsan's runtime calls are a good example of this. Attached is my attempt

On Feb 20, 2013, at 7:52 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: >>> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

On 23 Feb 2013, at 00:26, John McCall <rjmccall at apple.com> wrote: > On Feb 20, 2013, at 7:52 PM, John McCall <rjmccall at apple.com> wrote: >> On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: >>>> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at

BGB wrote: > > for x86: > I presume LLVM supports inline assembler, and also uses the traditional > frame pointer-based stack layout, but I don't know the details (people who > know LLVM could probably be more helpful here). > > ok, maybe here is an option: > after getting the value (in the created stub), execute a chunk of inline > assembler to modify the caller

On Wed, 7 Nov 2007, Nicolas Geoffray wrote: > Thanks BGB, but at this point I can handle it ;-). The problem is not > how in theory (patch the caller), but how in the LLVM code generation > process. There are three steps for that: > > 1) How to represent the stub in the IR? An intrinsic? An external field > with a ghost linkage? Probably an intrinsic. The trick is making it

Hi, I was investigating some performance issues with llvm JIT-generated code (x86_64), and looking at the assembly it indeed seemed quite suboptimal. In particular, the code is basically implementing some kind of caching. If there's a cache hit, the code just takes the value from the cache, if not it will do whatever is necessary to update the cache - this is expensive but happens only in

Thanks for giving it a look! On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > >> So I saw that the code is doing lots of register >> spilling/reloading. Now I understand that due to calling >> conventions, there's not really a way to avoid this - I tried using >> coldcc but apparently the backend

On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > So I saw that the code is doing lots of register spilling/reloading. Now > I understand that due to calling conventions, there's not really a way > to avoid this - I tried using coldcc but apparently the backend doesn't > implement it and hence this is ignored. Yes, unfortunately the list of call-clobbered registers is

> On Dec 1, 2015, at 11:14 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > While we support 'opaque' types nested within struct types, they are not exactly battle tested: > > $ cat t.ll > %opaque_ty = type opaque > > %struct_ty = type { i32, %opaque_ty } > > define %struct_ty @f(%struct_ty* %p) { > %load = load %struct_ty,

Hi David, Sorry to bother you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid

On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > Thanks for giving it a look! > > On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >> >>> So I saw that the code is doing lots of register >>> spilling/reloading. Now I understand that due to calling >>> conventions, there's not

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with

Hi llvmdev, I'm trying to figure how llvm remembers stack slots allotted to callee saved registers on x86. In particular, llvm pushes registers in decreasing order of FrameIdxs [1], so the offsets they get (as returned by MFI->getObjectOffset) don't directly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll

> > I assume with target you mean the backend? Consider the x86 backend. It > supports 32bit and 64bit mode, with the GNU x32 ABI in between. There > are three different executable formats support (ELF, PE, MachO) with > different constraints. Some platforms require 32bit alignment of the > stack, others require 128bit alignment. The list goes on. The triple > specifies >

https://superjoe.s3.amazonaws.com/temp/repro.tar.xz On Mon, Apr 2, 2018 at 1:26 PM, Rui Ueyama <ruiu at google.com> wrote: > Can you add `--reproduce=repro` to lld command line? That generates > repro.tar in your current directory which contains all input files. And > then please compress and upload it somewhere so that we can take a look. > > > On Mon, Apr 2, 2018 at

I have never used -> but I noticed at http://github.com/jiho/r-utils/blob/master/beamer_colors.R that some people do. In fact, the above-named code has a sort of elegance about it (except for the use of "=" for assignment...). To my eye, -> calls to mind a type of assignment that is meant to stand out. For example, perhaps it would make sense to use -> to assign