search for: isascheapasamov

In BPF, an ADD instruction is defined as a 2 register instruction: 0x0f. add dst, src. dst += src In BPFInstrInfo.td this kind of ALU instruction is defined with: def _rr : ALU_RR<BPF_ALU64, Opc, (outs GPR:$dst), (ins GPR:$src2, GPR:$src), "$dst "#OpcodeStr#" $src", [(set

Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some

...so important to get in: > > r352240 | asb | 2019-01-25 13:06:47 -0800 (Fri, 25 Jan 2019) | 7 lines > [RISCV] Add another potential combine to {double,float}-bitmanip-dagcombines.ll > > r352237 | apazos | 2019-01-25 12:22:49 -0800 (Fri, 25 Jan 2019) | 3 lines > Reapply: [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUI > > r352211 | asb | 2019-01-25 08:04:04 -0800 (Fri, 25 Jan 2019) | 6 lines > [RISCV][NFC] s/f32/f64 in double-arith.ll > > r352199 | asb | 2019-01-25 06:33:08 -0800 (Fri, 25 Jan 2019) | 8 lines > [RISCV] Add tests to demonstrate bitcasted fneg/fabs dagcom...

...a bug? MachineCSE skips cheap instructions on purpose: // Heuristics #1: Don't CSE "cheap" computation if the def is not local or in // an immediate predecessor. We don't want to increase register pressure and // end up causing other computation to be spilled. if (MI->isAsCheapAsAMove()) { MachineBasicBlock *CSBB = CSMI->getParent(); MachineBasicBlock *BB = MI->getParent(); if (CSBB != BB && !CSBB->isSuccessor(BB)) return false; } This code is older than the greedy register allocator. We could delete it if somebody is willing to check for r...

Hello, My out-of-tree target features some high latency instructions (let's call them FXLV). When an FXLV issues, it reserves its destination register and execution continues; if a subsequent instruction attempts to read or write that register, the pipline will stall until the FXLV completes. I have attempted to encode this constraint in the machine scheduler (excerpt at bottom of email).

Hello > and as the return value. Is this a missed optimization from LLVM or did i > miss something out? > Changing the register allocation order didnt work. What are the patterns for xor / mov ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...tructions on purpose: > > // Heuristics #1: Don't CSE "cheap" computation if the def is not local > or in > // an immediate predecessor. We don't want to increase register pressure > and > // end up causing other computation to be spilled. > if (MI->isAsCheapAsAMove()) { > MachineBasicBlock *CSBB = CSMI->getParent(); > MachineBasicBlock *BB = MI->getParent(); > if (CSBB != BB && !CSBB->isSuccessor(BB)) > return false; > } > > This code is older than the greedy register allocator. We could delete it &gt...

> I expected that this optimization would be picked > up in a cse, gvn, machine-cse or even peepholing pass. > > Comments? At the LLVM IR level this is represented as define i64 @caller() #0 { entry: store i64* @val, i64** @p, align 8, !tbaa !0 store i64 12345123400, i64* @val, align 8, !tbaa !3 %call = tail call i64 @xtr(i64 12345123400) #2 ret i64 %call } Which is

...After annotating the pattern with above flags, RegisterCoalescer::reMaterializeTrivialDef still bails out because the above assignment has 2 definitions, with only one live definition. To address this issue, I attached a hackish patch that (a) Marks tMOVi8 pattern with: let isReMaterializable = 1, isAsCheapAsAMove = 1, isMoveImm = 1 I am not sure if this is entirely correct ? (b) Modifies RegisterCoalescer::reMaterializeTrivialDef and TargetInstrInfo::isReallyTriviallyReMaterializableGeneric to check for single live def, instead of single def. Does the patch look in the right direction ? For the above tes...

For the little C test program where a constant is stored in memory and also used as a parameter: #include <stdint.h> uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq

Hello, while testing trivial functions in my backend i noticed a suboptimal way of assigning regs that had the following pattern, consider the following function: typedef unsigned short t; t foo(t a, t b) { t a4 = b^a^18; return a4; } Argument "a" is passed in R15:R14 and argument "b" is passed in R13:R12, the return value is stored in R15:R14. Producing the

Dear testers, 8.0.0-rc1 was just tagged (from the branch at r351980). It took a little longer than planned, but it's looking good. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we