similar to: [LLVMdev] Is addrspacecast implemented on Windows?

Hi all, the addrspacecast stuff has landed and I'm now seeing failures in our back end because clang is emitting them, they're travelling through the IR to the SelectionDAG, and there's nothing to match them. Trying to match them, I get an error from TableGen saying: Variable not defined: 'addrspacecast' If I try to set a custom OperationAction in the target lowering class

Hi, I'd like to add support for addrspacecast in initializers of global variables, at least for the trivial case. The trivial case is if TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In this case the MCExpr for the addrspacecast is the MCExpr of its first operand. It seems hard to obtain an instance of TargetLowering in AsmPrinter::lowerConstant(). Other methods in

The following combine(-enabling transformation) makes me uncomfortable:   gep(addrspacecast(gep p0) to p1)   addrspacecast(gep(gep p0)) to p1 It's applied at visitAddrSpaceCast in InstCombineCasts.cpp. Before this, I'd always assumed address spaces were very much "user domain". Datalayout even supports marking a space as "non-integral", to designate that manipulation as

On 16 Mar 2015, at 08:25, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > The LangRef says this about addrspacecast: "Note that if the address > space conversion is legal then both result and operand refer to the > same memory location.". This brings forth two related questions: > > 1. what happens if you execute an "invalid" addrspacecast?

Given a pointer, does any addrspacecast affect the pointer's dereferenceablity ? For example, %pm = addrspaacecast float addrspacecast(n)* %pn to float addrspacecast(m)* %r = load float addrspace(m)* %pm In another word. the question is whether the following is true ? isDereferenceablePointer(pn) == isDereferenceablePointer(pm) [Note that the function is defined as

I was reading the LangRef for semantics of an instruction and came across addrspacecast. I've never needed it, so I suppose I don't care about it. But, why does it exist? What problem is it trying to solve?

In the following example, for some reasons, the input pointer entering the loop was casted to generic pointer. How can the backend get rid of the addrspacecast and use local store in the loop? for.body.lr.ph: ; preds = %entry %0 = addrspacecast i32 addrspace(3)* %in to i32 addrspace(4)* br label %for.body for.body: ; preds = %for.body, %for.body.lr.ph %i.03 = phi i32 [ 0, %for.body.lr.ph ],

On 17 Mar 2015, at 20:06, Junjie Gu <jgu222 at gmail.com> wrote: >> I've just been debugging a related issue with regard to commutativity of address space casts with respect to other operations. One of the optimisers is turning an add after an address space cast into an add before the address space cast. On our architecture, this results in different bounds information being

> What do you mean exactly by "behave differently on the other side of the cast”? Do you have a concrete example? I was hesitant to say only in that it is probably an "abuse of mechanics" and definitely playing with fire, _however_ the target I'm working on has extensive bit operations for a subset of memory, including atomic test-and-set, etc. It's convenient to be

Hi, On 15.04.2014 23:44, Vadim Chugunov wrote: > Hi, > I am curious - how does clang deal with epilogue-less functions that > result from _Raise_Exception being marked 'noreturn'? > I've also been playing with Kai's patch, and discovered that this tends > to greatly confuse Windows stack unwinder in cases when noreturn call is > at the end of a function, so

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

On 11 December 2013 05:41, Kai Nacke <kai.nacke at redstar.de> wrote: > Maybe we should also change the stack probing code. I think ___chkstk_ms is > used since gcc 4.6. It simplifies the prologue generation code a bit. I just checked gcc 4.6 and looks like you are right, it uses ___chkstk_ms. LGTM. We should probably commit this first, since it is common for gcc 4.6 and newer.

It appears that this behaviour of InstCombine is at least somewhat intended, as there are several tests that fail after the change mentioned before: cast.ll, gep-addrspace.ll and getelementptr.ll in test/Transforms/InstCombine. I feel a little uncomfortable applying the patch after knowing this, and removing those tests doesn't seem like a great solution. What are your thoughts? For now, I

Can you clarify what you mean by "real SEH handling"? My company has me looking at this in the hopes that I can make LLVM capable of building windows drivers. If you mean "visual c++ style SEH", I'm fairly sure that isn't necessary for my purposes, but it would be nice. If you mean "something that works at all," then your concern about generalizing LLVM

Hi all, I use the nightly builds of LLVM in my Travis CI configuration. Travis CI is based on Ubuntu 12.04 precise. Currently, I am not able to install llvm-3.4 and llvm-3.4-dev. The error is always: $ sudo apt-get install llvm-3.4 llvm-3.4-dev Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package llvm-3.4 E: Couldn't find any

Hi Rafael, is there a repository with the static pages or should I simply produce a diff between the 2 versions? Regards, Kai On 03.12.2013 14:30, Rafael Espíndola wrote: > Can you send a patch? > > On 2 December 2013 06:44, Kai Nacke <kai at redstar.de> wrote: >> Hi! >> >> I like to submit some updates to the LLVM website regarding the LDC >> compiler.

Hi Rafael, is more approval needed to commit? Regards, Kai On 12.12.2013 00:56, Rafael Espíndola wrote: > On 11 December 2013 05:41, Kai Nacke <kai.nacke at redstar.de> wrote: >> Maybe we should also change the stack probing code. I think ___chkstk_ms is >> used since gcc 4.6. It simplifies the prologue generation code a bit. > > I just checked gcc 4.6 and looks like

On 12 December 2013 14:01, Kai Nacke <kai.nacke at redstar.de> wrote: > Hi Rafael, > > is more approval needed to commit? No, go for it. Cheers, Rafael

Hi! I like to submit some updates to the LLVM website regarding the LDC compiler. All links are currently out-of-date. The following pages need updates: On page http://www.llvm.org/Users.html, please replace the existing entry "LLVM D Compiler" in section "Open Source Projects" with: <tr> <td><a href="http://wiki.dlang.org/LDC/">

Hi! I created a bug report (https://llvm.org/bugs/show_bug.cgi?id=23712) for this failure but then I realized that my approach may be wrong. The following D source contains a lazy variable: void bar(lazy bool val) { val(); } The lazy variable val is translated to a delegate. The signature and the first IR lines are: define void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 {