search for: pseudoinstruct

Displaying 20 results from an estimated 20 matches for "pseudoinstruct".

2018 Jul 10
6
[RISCV][PIC] Lowering pseudo instructions in MCCodeEmitter vs AsmPrinter
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...
2011 Aug 30
2
[LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn)
...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...
2011 Aug 30
0
[LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn)
...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 t...
2011 Aug 30
2
[LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn)
...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 th...
2012 Apr 29
1
[LLVMdev] Not enough optimisations in the SelectionDAG phase?
...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-instruct...
2013 Mar 06
3
[LLVMdev] ARM assembler's syntax in clang
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 a...
2011 Aug 30
0
[LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn)
...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 the...
2005 Mar 25
0
[LLVMdev] Stack alignment problem
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
2013 Mar 07
0
[LLVMdev] ARM assembler's syntax in clang
...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...
2005 Mar 23
2
[LLVMdev] Stack alignment problem
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
2018 Apr 30
0
LLVM Weekly - #226, Apr 30th 2018
...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 emiss...
2012 Apr 29
0
[LLVMdev] Not enough optimisations in the SelectionDAG phase?
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
2018 Jun 13
12
RFC: Atomic LL/SC loops in LLVM revisited
.../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 unc...
2019 Jun 11
2
Support 64-bit pointers in open source RV32 GPU ISA using register pairs and address space ID’s
> > 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,
2013 Mar 05
0
[LLVMdev] ARM assembler's syntax in clang
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
2018 Sep 20
2
Errononous scheduling of COPY instruction.
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;
2012 Apr 25
3
[LLVMdev] Not enough optimisations in the SelectionDAG phase?
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
2011 Aug 30
5
[LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn)
...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 b...
2013 Mar 04
2
[LLVMdev] ARM assembler's syntax in clang
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
2018 Sep 21
2
[GlobalISel] Legalize generic instructions that also depend on type of scalar, not only scalar size
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