similar to: wrong imm value for branch conditions..

Hi, *case MICROBLAZE::BGEID:* * {* * // op: raencoder* * op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI);* * Value |= (op & UINT64_C(31)) << 16;* * // op: imm16* * op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); -> should be operand[1]* * Value |= op & UINT64_C(65535);* * break;* * }* I have added

Hi In my MC6809 backend, in llvm/lib/Target/MC6809/InstPrinter/MC6809InstPrinter.cpp, I have the routine void MC6809InstPrinter::printPCRelImmOperand(const MCInst *MI, unsigned OpNo, raw_ostream &O) { const MCOperand &Op = MI->getOperand(OpNo); ZZ if (Op.isImm()) { int64_t Imm = Op.getImm() + 2; <<<======================== O << "$"; if (Imm

Gang, I'm tasked with direct object generation for Mips and am trying to not hack the code. I how exactly does one set an expression to be PC relative and if the compiler can resolve it, not produce a relocation? In our case, the backend produces an expression for the branch which is the target label. I make a call from the .td for the branch instruction which calls a routine in

On Oct 10, 2011, at 10:11 AM, Jack Carter wrote: > Gang, > > I'm tasked with direct object generation for Mips and am trying to not > hack the code. > > I how exactly does one set an expression to be PC relative and if the > compiler can resolve it, not produce a relocation? > Fixups are created for all expressions that may need a relocation. The MC layer evaluates

On 04/20/2015 01:25 PM, David Majnemer wrote: > These optimizations are not always run on IR that is fed to the backend. The DAG combiner also performs the undefined shift -> undef though, so it should still be OK -Matt

The generic code in lib/CodeGen has no knowledge of these semantic differences. This knowledge is only available on a per-target basis. Typical query functions would be X86InstrInfo::getMemOpBaseRegImmOfs(...) or AArch64::getMemOpInfo(...). Doing this in a common way accross targets requires callbacks in TargetInstrInfo, there seem to be some in that direction but they appear to be rarely used so

So I'd like to be able to tell the difference between an imm and an imm used in mem offset in MachineInstr. Or, it would be nice to tell the difference between src and dst operands. I must be missing something trivial? For example, int *b, a; b[10] = a + 2; // is there any marker/flag between 2 and 10 to tell the difference? Thanks. -------------- next part -------------- An HTML

For example: unsigned int x, y; void foo() { y = x >> 129; } Where int is a 16bit type, the .ll is producing only 'ret void' at O3. At O0 the .ll looks fine but then llc gets rid of it an simply returns. I'm just curious what the reasoning is for this? It isn't trying to set y to anything at all. Thanks. -------------- next part -------------- An HTML attachment was

There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946> - Matthias > On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> The DAG combiner also performs the undefined shift -> undef though, so it >> should still be OK > > DAG combiner doesn't really run to

Ok, this makes sense. So, my follow up is then why, as in Mips, R600, etc... the bit value is checked in the tablegen. Seems that we should expect it to fit anyways if it still exists at this point? I'm having a hard time trying to get shl to take a PatLeaf for Imm instead of an ImmLeaf. On Mon, Apr 20, 2015 at 4:11 PM, David Majnemer <david.majnemer at gmail.com> wrote: > >

Add a specific optimisation pass for NV50 to check whether SRC0 or SRC1 is a MOV dst, IMM. If so: fold the IMM in and try to drop the MOV. Must be done post-RA because it is required that SDST == SSRC2. Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git

And you're allowing saturate/neg emission on the short form. Is this already in envytools? Also, what's the shortForm thing? This change is probably fine, but the changelog needs work. On Sat, Jan 10, 2015 at 7:22 PM, Roy Spliet <rspliet at eclipso.eu> wrote: > MAD IMM has a very specific SDST == SSRC2 requirement, so don't emit > > Signed-off-by: Roy Spliet <rspliet

Add a specific optimisation pass for NV50 to check whether SRC0 or SRC1 is a MOV dst, IMM. If so: fold the IMM in and try to drop the MOV. Must be done post-RA because it requires that SDST == SSRC2. V2: improve readability and add comments to clarify decisions Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 60

Add a specific optimisation pass for NV50 to check whether SRC0 or SRC1 is a MOV dst, IMM. If so: fold the IMM in and try to drop the MOV. Must be done post-RA because it requires that SDST == SSRC2. V2: improve readability and add comments to clarify decisions V3: Remove redundant code... compiler already attempts to put the IMM in SSRC1 Signed-off-by: Roy Spliet <rspliet at eclipso.eu>

Add a specific optimisation pass for NV50 to check whether SRC0 or SRC1 is a MOV dst, IMM. If so: fold the IMM in and try to drop the MOV. Must be done post-RA because it requires that SDST == SSRC2. V2: improve readability and add comments to clarify decisions V3: Remove redundant code... compiler already attempts to put the IMM in SSRC1 Signed-off-by: Roy Spliet <rspliet at eclipso.eu>

Hi When I run a program I've written with Delphi7, I get several of the following messages: fixme:imm:ImmReleaseContext (0x10020, 0x403b9e80): stub . . . The program works - but is there anything I can do to avoid these messages? Rainer -- Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology and Entomology University of Stellenbosch

I have some code such that: vgpr1 = mov 0 branch bb bb: PHI vgpr2 = vgpr1, …. PHI vgpr3 = vgpr1, …. PHI vgpr4 = vgpr1, …. PHI vgpr5 = vgpr1, …. PHI node elimination is generating copies for all these PHIs (and hoisting them) as such: vgpr1 = 0 vgpr20 = COPY vgpr1 // old vgpr2 vgpr30 = COPY vgpr1 // old vgpr3 vgpr40 = COPY vgpr1 // old vgpr4 vgpr 50 = COPY vgprt1 // old vgpr5 I expect the zero

On Tue, 16 Jun 2020 at 15:47, Tim Northover <t.p.northover at gmail.com> wrote: > > On Tue, 16 Jun 2020 at 10:23, Prathamesh Kulkarni via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > (b) Modifies RegisterCoalescer::reMaterializeTrivialDef and > > TargetInstrInfo::isReallyTriviallyReMaterializableGeneric to check > > for single live def, instead of

Hi, For the following test-case: void foo(unsigned, unsigned); void f() { foo(10, 20); foo(10, 20); } clang --target=arm-linux-gnueabi -mthumb -O2 generates: push {r4, r5, r7, lr} movs r4, #10 movs r5, #20 movs r0, r4 movs r1, r5 bl foo movs r0, r4 movs r1, r5 bl foo pop {r4,

Op 11-01-15 om 01:34 schreef Ilia Mirkin: > And you're allowing saturate/neg emission on the short form. Yes > Is this already in envytools? Tesla floating point instructions are poorly documented in the RST documents; fmad is no exception. I'll make sure to check envydis. > Also, what's the shortForm thing? Documented in envytools; see