search for: sdag

You are right: select in SDAG has to be poison-blocking as well, otherwise the current lowering from IR's select to SDAG's select would be wrong. Which makes the select->or transformation incorrect at SDAG level as well. I guess until recently people believed that poison in SDAG wasn't much of a problem (...

> Transforms/InstCombine/select.ll > ================================ > define i1 @trueval_is_true(i1 %C, i1 %X) { >  %R = select i1 %C, i1 1, i1 %X >  ret i1 %R > } > => > define i1 @trueval_is_true(i1 %C, i1 %X) { >  %R = or i1 %C, %X >  ret i1 %R > } > ERROR: Target is more poisonous than source (when %C = #x1 & %X = poison) > > (there are

I am hoping that someone can offer advice on a somewhat unusual issue that I am facing with the SDAG. Namely, I am trying to implement some custom operations that do very specific things on multiple registers at a time. The operations themselves will simply be intrinsics since there are no equivalent operations in IR/SDAG. However, handling the types seems rather tricky. One approach I tried is t...

I am wondering if there is a good/easy way to recover the original type of a pointer parameter in the SDAG. Here's the problem that I am dealing with: define <4 x i32> @test(i32* nocapture readonly %a) local_unnamed_addr #0 { entry: %0 = bitcast i32* %a to <4 x i32>* %1 = load <4 x i32>, <4 x i32>* %0, align 16, !tbaa !2 ret <4 x i32> %1 } The problem is that th...

On 26 Dec 2016, at 14:58, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am wondering if there is a good/easy way to recover the original type of a pointer parameter in the SDAG. Here's the problem that I am dealing with: > > define <4 x i32> @test(i32* nocapture readonly %a) local_unnamed_addr #0 { > entry: > %0 = bitcast i32* %a to <4 x i32>* > %1 = load <4 x i32>, <4 x i32>* %0, align 16, !tbaa !2 > ret <4 x i32&gt...

...David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 26 Dec 2016, at 14:58, Nemanja Ivanovic via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I am wondering if there is a good/easy way to recover the original type > of a pointer parameter in the SDAG. Here's the problem that I am dealing > with: > > > > define <4 x i32> @test(i32* nocapture readonly %a) local_unnamed_addr #0 > { > > entry: > > %0 = bitcast i32* %a to <4 x i32>* > > %1 = load <4 x i32>, <4 x i32>* %0, align 16,...

...ds/stores/calls/returns have? > (maybe i don't understand concept of side effect ) suppose you do a store to a memory location, and then load from the memory location. This is not the same as first doing the load and then only afterwards doing the store! How to represent the order in the SDAG? The SDAG is not a linear sequence of instructions like LLVM IR in a basic block. In the SDAG things are related only via "uses", eg: node A uses a result of node B. So to represent order relationships (this load must occur after that store), nodes are given an additional artificial re...

Hi, As part of the effort to bring up GlobalISel, I would like your feedbacks on the best way to map LLVM IR values into MachineInstr values (virtual registers), in particular when aggregate types get involved. I am looking for a long term solution. Short term is to replicate SDAG solution. ** Context ** The first step of GlobalISel is to translate the LLVM IR into MachineInstr representation. During this process we need to be able to tell where are the different LLVM IR values with respect to their machine representation, such that we can feed the right element to the re...

Hi everyone, It says in document 'The LLVM Target-Independent Code Generator ': "SelectionDAGs contain two different kinds of values: those that represent data flow and those that represent control flow dependencies. Data values are simple edges with an integer or floating point value type. Control edges are represented as "chain" edges which are of type MVT::Other. These

...alISel, I would like your >> feedbacks on the best way to map LLVM IR values into MachineInstr >> values (virtual registers), in particular when aggregate types get >> involved. >> >> >> I am looking for a long term solution. >> Short term is to replicate SDAG solution. >> >> >> >> >> ** Context ** >> >> >> The first step of GlobalISel is to translate the LLVM IR into >> MachineInstr representation. During this process we need to be able >> to tell where are the different LLVM IR values wi...

...nformation, such as the relocation model, code model > and visibility, to identify "fixed" globals, although that can be done > separately. > > > Ok, I think I understand the use-case. > > I have been experimenting with a number of approaches to representation in > SDAG, and I have found one that seems to work best, and would be the least > intrusive (unfortunately most approaches to this problem are somewhat > intrusive). > > Specifically, I want to: > 1) move most of the body of ConstantSDNode to a new class, > ConstantIntSDNode, which would de...

On 26 Dec 2016, at 15:49, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > David, thank you for the prompt response. > I originally implemented this with a check of getAlignment(). However, both getAlignment() and getOriginalAlignment() on the <4 x i32> load return the stronger alignment (16) rather than the alignment that the i32* parameter would have (4). > >

...wo vectors with the 8 ints, > > This might sound like a dumb question, but how does one build a vector of ints out of regular ints in IR? See: http://llvm.org/docs/LangRef.html#vector-operations In short, the IR has "insertelement", which maps to "INSERT_VECTOR_ELT" in SDAG and "extractelement", which maps to "EXTRACT_VECTOR_ELT" in SDAG. I usually find good example by grepping in the lit tests. Another way is to write the function in clang, and run it with -O3 -emit-llvm -S to get a good starting point. -- Mehdi > > sum them, and sto...

...lus side, freeze can helps us get rid of a bunch of miscompilations, which no one enjoys. The usage of freeze can be incremental; we can try out with a few things to see how it goes. We have more radical ideas down the road, like replace undef with poison, but one thing at a time :) Regarding SDAG, and given that poison is already there, we would need to adopt a similar solution to the IR. Maybe right now we can get away with it because nsw is not exploited significantly (as you say). Just because there’s no explicit poison in SDAG, just having nsw is sufficient to cause miscompilations wh...

On Tue, Oct 11, 2016 at 2:48 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 11, 2016, at 12:04 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I have been experimenting with a number of approaches to representation in >> SDAG, and I have found one that seems to work best, and would be the least >> intrusive (unfortunately most approaches to this problem are somewhat >> intrusive). >> >> Specifically, I want to: >> 1) move most of the body of ConstantSDNode to a new class, >> ConstantI...

...[LLVMdev] Enable changing UnsafeFPMath on a per-function basis > > > > Whatever happened to tracking the safe-or-fast-ness of FP math on > instructions? Is tracking this property at a function granularity > correct? I seem to recall nobody wanted to thread this through the > SDAG. No, I think we did want to do that, just no one has yet done it. We now have NSW/NUW in SDAG, so it should not be too much different for the FP flags. -Hal > > > If we agree that we want to track this at the function level, then > your proposal seems reasonable. > > >...

...sting implementation, I don’t see anything that would particularly be problematic for us to do it at the IR level. The existing TLI hooks to specify how certain memcpy calls should be lowered doesn’t have anything too SelectionDAG specific, and an IR lowering pass could be shared in future between SDAG and GISel. Does anyone see issues with this? Thanks, Amara

On Sat, Mar 02, 2019 at 07:34:50PM -0800, Tim Northover wrote: > The biggest difference and problem I see would be building the thing, > since the target's headers are going to be needed, but they're > private. That means they're not shipped with LLVM so you'd need the > source (and an active build directory for the TableGenerated files, >

...ate to SelectionDAG at -O0, we’re now starting to think about using GlobalISel with optimizations enabled. There are obviously many parts to this story as optimizations happen at various stages of the codegen pipeline. The focus of this RFC is the replacement of the equivalent of the DAGCombiner in SDAG land. Despite the focus on the DAGCombiner, since there aren’t perfect 1-1 mappings between SDAG and GlobalISel components, this may also include features that are currently implemented as part of the target lowerings, and tablegen isel patterns. As we’re starting from a blank slate, we have an opp...

...L(DAG, TLI, FuncInfo); + SelectionDAGLowering SDL(DAG, TLI, getAnalysis<AliasAnalysis>(), FuncInfo); std::vector<SDOperand> UnorderedChains; @@ -4191,7 +4363,7 @@ assert(SwitchCases.empty() && "Cannot have jump table and lowered switch"); SelectionDAG SDAG(TLI, MF, getAnalysisToUpdate<MachineDebugInfo>()); CurDAG = &SDAG; - SelectionDAGLowering SDL(SDAG, TLI, FuncInfo); + SelectionDAGLowering SDL(SDAG, TLI, getAnalysis<AliasAnalysis>(), FuncInfo); MachineBasicBlock *RangeBB = BB; // Set the current basic block to...