search for: pseudoinstructions

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 thi...

...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 way...

...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 e...

...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 r...

On 04/29/2012 01:19 PM, Evan Cheng wrote: > 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

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

...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 re...

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

Hi, Bernie, Thanks for your reply! However, I still have problem by following edk2's code, my test code is attached, what I want to do is build it as a dynamic lib. But I get error from ld: ld: illegal text-relocation to _data_table in table.o from foo in use_table.o for architecture armv7 Do you have any suggestion to solve this? Thanks! //==begin table.c== int data_table[] = {0xff, 0xff};

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

LLVM Weekly - #226, Apr 30th 2018 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/226>. Welcome to the two hundred and twenty-sixth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

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 uncondi...

> > 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 befor...

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