similar to: i1 true ^= -1 in DAG matcher?

The vnot PatFrag uses ImmAllOnesV which should put an OPC_CheckImmAllOnesV in the matcher table. And the matcher table should call ISD::isBuildVectorAllOnes. I believe we use vnot with vXi1 vectors on X86 and I haven't seen any issues. The FIXME you pointed to seems related to a scalar patcher not a vector pattern. In that case the issue is that the immediate matcher for scalars calls

A constant i1 is stored as a one bit APInt wrapped in a ConstantInt which is then wrapped in ConstantSDNode for SelectionDAG. The BUILD_VECTOR will just point to the same ConstantSDNode for each element. There is no concept of a sign in the storage. It's just a bit. Whether or not its treated as 1 or negative 1 is going to depend on the code looking at the value including printing code. And

or like this %cmp4 = icmp eq i32 %rem, 0 br i1 %cmp4, label %if.then5, label %if.else7 On 14 August 2013 20:08, Rasha Omar <rasha.sala7 at gmail.com> wrote: > Hi All, > > How could I use BranchInst to implement for example > br label %if.else7 > br label %if.then5 > br i1 %cmp4, label %if.then5, label %if.else7 > > I can use BranchInst for only one

Your question isn't clear; please restate what specifically isn't working. -Eli On Wed, Aug 14, 2013 at 11:57 AM, Rasha Omar <rasha.sala7 at gmail.com> wrote: > or like this > > %cmp4 = icmp eq i32 %rem, 0 > > br i1 %cmp4, label %if.then5, label %if.else7 > > > On 14 August 2013 20:08, Rasha Omar <rasha.sala7 at gmail.com> wrote: > >> Hi

How could BranchInst be used to insert new branch between two basic blocks to get result like this example: br label %if.else br label %if.then br i1 %cmp1, label %if.then, label %if.else Thanks for your help On 14 August 2013 21:36, Eli Friedman <eli.friedman at gmail.com> wrote: > Your question isn't clear; please restate what specifically isn't working. > > -Eli

When I compile two different modules using clang -O -S -emit-llvm I get different .ll files, no surprise. The first looks like double *v; double zap(long n) { double sum = 0; for (long i = 0; i < n; i++) sum += v[i]; return sum; } yielding @v = common global double* null, align 8 ; Function Attrs: nounwind readonly uwtable define double @zap(i64 %n) #0 { entry: %cmp4 =

Hi All, How could I use BranchInst to implement for example br label %if.else7 br label %if.then5 br i1 %cmp4, label %if.then5, label %if.else7 I can use BranchInst for only one instruction but how could I compare between two branches Thanks -- * Rasha Salah Omar Msc Student at E-JUST Demonestrator at Faculty of Computers and Informatics Benha University* *

On some targets with limited addressing modes, getting that 64-bit relocatable but loop-invariant value into a register requires several instructions. I'd like those several instruction outside the loop, where they belong. Yes, my experience is that something (I assume instcombine) recanonicalizes. Thanks, Preston On Tue, Dec 8, 2015 at 11:21 PM, Mehdi Amini <mehdi.amini at

I'm trying to make the IR "better", in a machine-independent fashion, without having to do any lowering. I've written code that rewrites GEPs as simple adds and multiplies, which helps a lot, but there's still some sort of re-canonicalization that's getting in my way. Is there perhaps a way to suppress it? Thanks, Preston On Wed, Dec 9, 2015 at 7:47 AM, Mehdi Amini

I suppose your view is reasonable, and perhaps common. My own "taste" has always preferred machine-independent code that is as simple as possible, so GEPs reduced to nothing more than an add, etc, i.e., quite risc-like. Then optimize it to reduce the total number of operations (as best we can), then raise the level during instruction selection, taking advantage of available instructions.

Hi! During my backend development I get the error message for some tests: *** Bad machine code: Virtual register def doesn't dominate all uses. *** (C source-code, byte-code disassembly and printed machine code at the end of the email) The first USE of vreg4 in BB#1 has no previous DEF in BB#0 or #1. But why? I can't see how the LLVM byte-code is transformed to the lower machine code.

Hi all, I have the following test case: #define FLT_EPSILON 1.19209290E-7 int err = -1; int main() { float a = 8.1; if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am using FLT_EPSILON to check whether (a != 2.0). err = 1; } else { err = 0; } return 0; } with -O3 optimization level clang generates already incorrect LLVM IR: ; Function Attrs:

A GEP can represent a potentially large tree of instructions. Seems like all the sub-trees are hidden from optimization; that is, I never see licm or value numbering doing anything with them. If I rewrite the GEPs as lots of little adds and multiplies, then opt will do a better job (I speculate this happens during lowering). One of the computations that's hidden in the GEP in my example is

Hi, I've prepared patches for both LLVM and Clang to change the datalayout for R600. This may seem like a bold move, but I think it is warranted. R600/SI is a strange architecture in that it uses 64bit pointers but does not support 64 bit arithmetic except for load/store operations that roughly map onto getelementptr. The current datalayout for r600 includes n32:64, which is odd

Hi Quentin, yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". I do have a very simple DAGToDAGISel::Select() method: SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) { SDLoc dl(N); // default implementation if (N -> isMachineOpcode()) { N -> setNodeId(-1); return NULL; // Already selected. } SDNode

I understand that GEPs do not access memory. They do a (possibly expensive) address calculation, perhaps adding a few values to a label and leaving the result in a register. Getting a label into a register is (to me) just like loading a 64-bit integer value into a register. It can happen in many places and it can cost a few instructions and several bytes. I'd like to see such things commoned

Hi Quentin, I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I found out, that some SDNodes are not passed to the ::Select(SDNode*N), approximately 11 nodes are missing. The first add-node (v1+v2) is missing. Is it normal that not all nodes are passes to ::Select()? Thanks,

Hi Quentin, Am 01.11.2014 um 00:39 schrieb Quentin Colombet <qcolombet at apple.com>: > > On Oct 31, 2014, at 11:00 AM, Boris Boesler <baembel at gmx.de> wrote: > >> Hi Quentin, >> >> I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I

Hi, When I write various test cases and explore how they're handled by the code in LoopDependenceAnalysis::analysePair, I'm surprised. This loop collects pairs of subscripts from the source and destination refs. * // Collect GEP operand pairs (FIXME: use GetGEPOperands from BasicAA), adding* * // trailing zeroes to the smaller GEP, if needed.* * GEPOpdsTy destOpds, srcOpds;* *

On Jul 21, 2009, at 11:14 PM, Eli Friedman wrote: > Testcase (compile with clang >= r76726): > #include <emmintrin.h> > __m128i a(__m128 a, __m128 b) { return a==a & b==b; } > > CodeGen ends up scalarizing the comparison, which is really bad, and > AFAIK different from what we did before vsetcc was removed. The ideal > code is a single cmpordps, although I