search for: isascheapasamov

Displaying 13 results from an estimated 13 matches for "isascheapasamov".

Did you mean: isascheapasamove
2020 May 12
2
BPF tablegen+codegen question
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
2017 Oct 17
2
getCacheSize() / subtarget machine id
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
2019 Jan 30
2
[8.0.0 Release] rc1 has been tagged
...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...
2013 Aug 02
2
[LLVMdev] Missing optimization - constant parameter
...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...
2017 Apr 03
2
Scheduler: modelling long register reservations?
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).
2010 Sep 04
0
[LLVMdev] Possible missed optimization?
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
2013 Aug 05
0
[LLVMdev] Missing optimization - constant parameter
...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...
2013 Aug 02
0
[LLVMdev] Missing optimization - constant parameter
> 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
2020 Jun 16
2
[ARM] Thumb code-gen for 8-bit imm arguments results in extra reg copies
...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...
2013 Aug 02
2
[LLVMdev] Missing optimization - constant parameter
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
2010 Sep 04
6
[LLVMdev] Possible missed optimization?
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
2019 Jan 24
14
[8.0.0 Release] rc1 has been tagged
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
2016 Nov 27
5
Extending Register Rematerialization
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