similar to: [LLVMdev] Load serialisation during selection DAG building

Steve, I had created a patch last year that does something similar to what you describe for regular loads and stores using aliasing information. I think that the last message in the thread was: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140299.html This approach has worked for me, but it is not the preferred solution going forward. The preferred solution is to keep the

I looked into those patches but I don't think they will help in my situation because my problems occur during instruction selection rather than scheduling. A simple and concrete example is a pattern like: [(set GR:$dst (add GR:$src (nvload addr:$mem)))] where nvload matches a load provided that isVolatile() is false. If the selection DAG looks like: | | LD1 LD2 ^

Further to my earlier question, I'm perhaps a bit confused about memory serialisation. The following example, compiled using clang for the MSP430: target datalayout = "e-p:16:16:16-i8:8:8-i16:16:16-i32:16:32-n8:16" target triple = "msp430-??-??" @y = common global i16 0, align 2 @x = common global i16 0, align 2 define void @f() nounwind { entry: %0 = load i16* @y,

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB

I posted to llvmdev a few months ago to ask for advice on the best way to avoid the SelectionDAGBuilder from imposing a constraint whereby a volatile load would be serialised relative to all pending loads. The LLVM LRM says that a volatile load only needs to be serialised relative to other volatile loads and, while it may not matter to most targets, the current behaviour of the SelectionDAGBuilder

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

Hi Chris, Your were totally right with your suggestion. I have implemented the code that : a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands. b) produces a bunch of TokenFactor nodes with at most 64 operands, instead of one huge TokenFactor in the SelectionDAGLowering::getRoot(). If we have n

Hello all, in SelectionDAGBuilder::handleBTSplitSwitchCase (lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp) seems to be a quirk which can effectively create an else-if chain from a very sparse switch statement instead of a balanced binary tree. A possible solution is to weight an isolated single switch label with 0. To do this one can replace the assignments to LDensity und RDensity by:

I need to generate line number debug information for PIC16 target. PIC16 does not support dwarf format. It supports coff format. So I need to custom handle the STOPPOINT nodes. Without -fast option the STOPPOINT nodes are not created in dag because of the below check in SelectionDAGBuild.cpp if (Fast) DAG.setRoot(DAG.getDbgStopPoint(getRoot(), If I give -fast option then the Fast

Hi all, I'm trying to play with patchoint (with MCJIT and VMKit) and I don't understand something. I generate this call for my first patch point. Basically, I want to call f(0). %5 = call i64 (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.i64( i64 42, ;; patch point id is 42 i32 0, ;; 0 bytes for the padding i8* bitcast (i32 (i32)* @f to i8*), ;; my function f i32 1,

patchpoint is intended to be used in VMs that do their own linking, and so you wouldn't expect the function parameter to be resolved by LLVM. Presumably, in VMKit, you could just plant a pointer constant to the function you wish to call initially? -Filip On Dec 17, 2013, at 2:42 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Hi all, > > I'm trying to play with

The z architecture is defined so that the equivalent of: while (*x == 0); is allowed to reuse the same value of *x indefinitely, even if another CPU writes to *x and synchronises the result to make it globally visible. There's no guarantee of forward progress without an explicit synchronisation on the read side. (Well, forward progress is guaranteed after an interrupt, and in practice

Hi, I have a question regarding PGO. I collected profile data with the instrumentation build (-fprofile-instr-generate) and provided for PGO optimization in the second build (with -fprofile-instr-use=xxx.profdata). This works fine. Then I tried to provide the profile data to opt using the option -pgo-instr-use, but this causes an error with the message: "Not an IR level instrumentation

Ok I see. Of course, at runtime, it's enough for dynamic linking or for deoptimization. However, wmkit acts both as a jit and as an aot. For the aot, it means that I can not use patchpoint and that I should have two different compilation strategy. It's not so difficult, but in this case, I can not use patchpoints to generate gc's stackmap for the aot (basically, I think that I could

Hi, it seems like SelectionDAGBuilder expects returning of vectors (structures/arrays) to be lowered in either of the two ways: 1. Flatten the complex data types to simple data types, and return them using registers (done by TargetLowering::LowerCallTo) 2. sret demotion: return the address of the complex data type via a stack pointer Is there an option to do sret demotion via a register? if yes,

Philip Reames wrote: > Any change outside of statepoint lowering is highly suspect. Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying) has exactly one other caller: visitCall, which doesn't match vararg functions. Every other codepath directly calls TargetLowering::LowerCallTo, supplying CallLoweringInfo information explicity (it's a structure with a vararg

The following problems happens with architectures, where stack alignment is smaller than the biggest preferred alignment for any data type SP pointer may point anywhere with alignment of stack alignment (4 in our case) SelectionDAGBuilder however calls CreateStackObject with preferred alignment is given data type(8 in our problemaric case. The ABI alignment for this data type is only 4) This

> what does "refuses to compile" mean? I.e. what error do you get? > Specifically I get this message when compiling with the default -mattr: Call result #2 has unhandled type i32 UNREACHABLE executed at CallingConvLower.cpp:162! 0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38 1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254 2