search for: pseudoinstruction

H all, I'm looking at generating PIC code for RISC-V in the context of Linux. Not sure if anyone is working on this already, any inputs are very welcome. I'm now looking at function calls which in the RISCV backend are represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL. Currently those pseudos are lowered in MCCodeEmitter. They are expanded into AUIPC and JALR instructions and the first one needs a relocation, which for a static reloc model is R_RISCV_CALL but for PIC code should be R_RISCV_CALL_PLT. The problem I find is that at th...

...ot; + PostEmitter + "(MI, Value);\n"; should be Case += " Value |= " + PostEmitter + "(MI, Value);\n"; This looks like it would affect all targets, except apparently only ARM uses this feature. 2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate. emitPseudoInstruction() asserts (llvm_unreachable). 3) FCONSTS/FCONSTD also assert similarly. emitMiscInstruciton which used to support these instructions was removed in r116644. If you try to add back a case for them in the obvious wa...

...as set them. If you're seeing incorrect output from the post-encoder hook, it's because the hook itself has a bug. > This looks like it would affect all targets, except apparently only ARM uses this feature. > > 2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate. emitPseudoInstruction() asserts (llvm_unreachable). This is another symptom of the non-MC ARM JIT being unmaintained. It is correct for emitPseudoInstruction() to assert. All pseudo instructions should be expanded before they reach the...

...hould instead be unsigned VFPThumb2PostEncoder(const MachineInstr&MI, unsigned Val) const { return Val; } >> This looks like it would affect all targets, except apparently only ARM uses this feature. >> >> 2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate. emitPseudoInstruction() asserts (llvm_unreachable). > > This is another symptom of the non-MC ARM JIT being unmaintained. It is correct for emitPseudoInstruction() to assert. All pseudo instructions should be expanded before they...

...because lui/ori are a pair of dependent ori instructions. There is a chicken-and-egg problem where neither can be hoisted without the other, and MachineLICM is not aggressive enough to recognize chains of dependent, loop-invariant cheap instructions. At the time, the advice was to implement a PseudoInstruction for lui+ori and lower it in a C++ pass, as is done in ARM (see MOVi32imm in ARMInstrInfo.td and ARMExpandPseudoInsts.cpp). I did this for my target and it worked fine, so MIPS could do the same. To me, that solution isn't too satisfying because you have to do this for every multi-instruction...

Hi Ashi, Your first LDR is a pseudoinstruction that is supported by some tools (gas and armasm, at least), but not by LLVM. Roughly speaking, it turns into a PC-relative load from a literal pool. To do what you're trying to achieve you can write your own literal pool in your assembly. You can see some examples of this sort of thing at h...

...should instead be unsigned VFPThumb2PostEncoder(const MachineInstr&MI, unsigned Val) const { return Val; } >> This looks like it would affect all targets, except apparently only ARM uses this feature. >> >> 2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate. emitPseudoInstruction() asserts (llvm_unreachable). > > This is another symptom of the non-MC ARM JIT being unmaintained. It is correct for emitPseudoInstruction() to assert. All pseudo instructions should be expanded before they r...

yOn Wed, 23 Mar 2005, Vladimir Prus wrote: >> How is your target different here? Can you give an example of why this >> causes a problem? > > Here's the code which computes the hasCalls flag: > > bool HasCalls = false; > > for (MachineFunction::iterator BB = Fn.begin(), E = Fn.end(); BB != E; ++BB) > for (MachineBasicBlock::iterator I = BB->begin(); I

...o $@ use_table.o:use_table.s $(CC) -c -integrated-as $(CFLAG) $^ -o $@ clean: rm *.o libtest.dylib test //==end Makefile== Cheers, Ashi On Wed, Mar 6, 2013 at 11:59 PM, Bernie Ogden <bogden at arm.com> wrote: > Hi Ashi,**** > > ** ** > > Your first LDR is a pseudoinstruction that is supported by some tools (gas > and armasm, at least), but not by LLVM. Roughly speaking, it turns into a > PC-relative load from a literal pool.**** > > ** ** > > To do what you're trying to achieve you can write your own literal pool in > your assembly. You can see...

On Tuesday 22 March 2005 20:34, Chris Lattner wrote: > Can you explain the problem in more detail? Specifically the LLVM code > gneerator assumes that there is some alignment that the stack is required > to have as part of its ABI. For example, in X86 target machine, the stack > is 8-byte aligned on entry to function calls. > > What this means is that the frame info can assume

...ress are of the form globaladdr + constant. [r330630](https://reviews.llvm.org/rL330630). * The new CFIInserter pass is used to ensure correct dwarf unwind information is emitted in the function epilogue. It is currently x86-only. [r330706](https://reviews.llvm.org/rL330706). * The 'call' pseudoinstruction is now supported by the RISC-V MC layer. [r330826](https://reviews.llvm.org/rL330826). * The MIPS backend gained support for the Virtualizations Application Specific Extension. [r331024](https://reviews.llvm.org/rL331024). ## Clang commits * The `-Qn` option can be used to suppress the emission...

On Apr 24, 2012, at 11:48 PM, Fan Dawei wrote: > For the following code fragment, > > ; <label>:27 ; preds = %27, %entry > %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8 > %29 = icmp slt i32 %28, 0 > br i1 %29, label %27, label %loop.exit > > loop.exit: ; preds = %27

.../lists.llvm.org/pipermail/llvm-dev/2016-May/099490.html>. The situation remains pretty much the same: * ARM and AArch64 expand to LL/SC loops in IR using AtomicExpandPass for O1 and above but use a custom post-regalloc expansion for O0 * MIPS doesn't use AtomicExpandPass, but selects atomic pseudoinstructions which it expands to LL/SC loops in EmitInstrWithCustomInserter. This still has the problems described above, so MIPS is in the process of moving towards a two-stage lowering, with the LL/SC loop lowered after register allocation. See D31287 <https://reviews.llvm.org/D31287>. * Hexagon uncond...

> > Hi Reshabh, and congratulations on being selected for GSoC. I haven't > looked at supporting larger than native-width pointers on a target > before. I'd thought that AVR might be relevant (given it uses 16-bit > pointers but has 8-bit GPRs). See the description here > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html>. > Many thanks Alex,

Hi, all. The previous post have a typo: problem in ARM assembly: I use LDR to load an external symbol : LDR R7,=DataTable But clang gives error: unexpected token in operand to the '=', Then I change the code to: LDR R7,DataTable The error becomes: unsupported relocation on symbol. How can I get around this in clang? My problem is actually how to load external symbol in

Hi, I've instruction scheduling problem that I cannot further investigate by myself... Could someone give me some clues? After Instruction selection, here is part of the generated instruction. NOP MOV_AB_ro @s1, %fab_roff0 %6:fpuaoffsetclass = COPY %fab_roff0; FPUaOffsetClass:%6 MOV_A_oo %6, def %5; FPUaOffsetClass:%6,%5 MOVSUTO_A_iSLo 24575, def %7;

For the following code fragment, ; <label>:27 ; preds = %27, %entry %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8 %29 = icmp slt i32 %28, 0 br i1 %29, label %27, label %loop.exit loop.exit: ; preds = %27 llc will generate following MIPS code, $BB0_1: lui $3, 32800 ori $3, $3, 1032 lw

...gned VFPThumb2PostEncoder(const MachineInstr&MI, unsigned Val) const { return Val; } > > >>> This looks like it would affect all targets, except apparently only ARM uses this feature. >>> >>> 2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate. emitPseudoInstruction() asserts (llvm_unreachable). >> >> This is another symptom of the non-MC ARM JIT being unmaintained. It is correct for emitPseudoInstruction() to assert. All pseudo instructions should be expanded befo...

Hi, all. Another problem in ARM assembly: I use LDR to load an external symbol : LDR R7,=DataTable But clang gives error: unexpected token in operand to the '=', Then I change the code to: LDR R7,=DataTable The error becomes: unsupported relocation on symbol. How can I get around this in clang? Thanks in advance! On Mon, Feb 25, 2013 at 7:14 PM, Ashi <ashi08104 at

Hi, Mips32 has 64 bit floating point instructions, while i64 instructions have to be emulated with i32 instructions. This means that G_LOAD should be custom legalized for s64 integer value, and be legal for s64 floating point value. There are also other generic instructions with the same problem: G_STORE, G_SELECT, G_EXTRACT, and G_INSERT. There are also other configurations where integer