Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] Call instruction"
2009 Jan 07
4
[LLVMdev] Possible bug in the ARM backend?
Hi,
I'm working on the iterated register coalescing graph coloring
allocator and try to test it with all backends available currently in
LLVM.
Initial tests with most of the backends are successful.
It turned out that my allocator triggers a specific assertion in the
RegScavenger and only for the ARM target. It looks like the LR
register is used for frame pointer related things,
but it is
2009 Jan 13
2
[LLVMdev] Possible bug in the ARM backend?
2009/1/13 Evan Cheng <echeng at apple.com>:
>
> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>
>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>> Predecessors according to CFG: 0x8fdac90 (#0)
>> %R0<def> = MOVi 0, 14, %reg0, %reg0
>> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>> [0x8fc2d68 + 0]
2009 Jan 13
0
[LLVMdev] Possible bug in the ARM backend?
On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
> Predecessors according to CFG: 0x8fdac90 (#0)
> %R0<def> = MOVi 0, 14, %reg0, %reg0
> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
> [0x8fc2d68 + 0]
> %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>
2018 Jun 15
2
Strange Machineinstr
Hi
I write a machinefunction pass to print all the machinefunction's machine
instructions.
My target architecture is ARM. However, I don't understand some part of the
machine instructions.
Below is some of the assembly language for function A.
.text:0001C034 STMFD SP!, {R4,R10,R11,LR}
> .text:0001C038 ADD R11, SP, #8
> .text:0001C03C
2018 Jun 15
3
Strange Machineinstr
Hi Krzysztof
Thank you very much for your quick and clear reply. I know that MIR may not
match hardware instructions directly. However, I think the semantics should
be similar.
For example, the first instruction is a store-multiple instruction in ARM.
I think the first four MIR I shown should have the similar semantics with
the first three hardware instructions. I still cannot see the
2009 Jan 13
0
[LLVMdev] Possible bug in the ARM backend?
On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com
> wrote:
> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>
>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>
>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>> Predecessors according to CFG: 0x8fdac90 (#0)
>>> %R0<def> = MOVi 0, 14, %reg0,
2009 Jan 13
2
[LLVMdev] Possible bug in the ARM backend?
Hi again,
2009/1/13 Evan Cheng <evan.cheng at apple.com>:
>
>
> On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com>
> wrote:
>
>> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>>
>>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>>
>>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
2009 Jan 09
0
[LLVMdev] Possible bug in the ARM backend?
This looks like a bar in ARMInstrInfo.td:
BX_RET should be marked with Uses = [LR] since it uses LR. However,
this won't work if there is a call BL before the BX_RET. BL is marked
as if it implicitly define LR. So we'll end up with this (hello world
example):
Live Ins: %LR %R7
%SP<def> = SUBri %SP<kill>, 8, 14, %reg0, %reg0
STR %LR<kill>, %SP,
2017 Nov 07
4
Questions about code-size optimizations in ARM backend
Hi All,
I started to work on code-size improvements on ARM target by comparing
GCC and LLVM generated code.
My first candidate was switch-case lowering.
I also created a Bugzilla issue for this topic:
https://bugs.llvm.org/show_bug.cgi?id=34902
The full example code and the generated assembly for GCC and for LLVM is
in the Bugzilla issue.
My first idea was to simplify the following
2009 Jan 09
1
[LLVMdev] Possible bug in the ARM backend?
On Jan 9, 2009, at 11:37 AMPST, Evan Cheng wrote:
> This looks like a bar in ARMInstrInfo.td:
>
> BX_RET should be marked with Uses = [LR] since it uses LR. However,
> this won't work if there is a call BL before the BX_RET. BL is marked
> as if it implicitly define LR. So we'll end up with this (hello world
> example):
PPC has the call (BL) marked with Defs=LR and the
2020 Apr 15
4
[ARM] Register pressure with -mthumb forces register reload before each call
Hi,
I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo.
For the following case:
void f(int x, int y, int z)
{
void bar(int, int, int);
bar(x, y, z);
bar(x, z, y);
bar(y, x, z);
bar(y, y, x);
}
it calls foldMemoryOperand twice, and thus converts two calls from blx to bl.
callMI->dump() shows the function name "bar" correctly, however in
generated
2017 Oct 09
4
{ARM} IfConversion does not detect BX instruction as a branch
Hi all,
I got a silly bug when compiling our project with the latest Clang.
Here's the outputted assembly:
> tst r3, #255
> strbeq r6, [r7]
> ldreq r6, [r4, r6, lsl #2]
> strne r6, [r7, #4]
> ldr r6, [r4, r6, lsl #2]
> bx r6
For the code to execute correctly, either the _ldr_ should be a _ldrne_
instruction or the _ldreq_ instruction should be removed. The error
seems to
2020 Apr 15
2
[ARM] Register pressure with -mthumb forces register reload before each call
On Wed, 15 Apr 2020 at 03:36, John Brawn <John.Brawn at arm.com> wrote:
>
> > Could you please point out what am I doing wrong in the patch ?
>
> It's because you're getting the function name by doing
> callee->getName().str().c_str()
> The str() call generates a temporary copy of the name which ceases to exist outside of this expression
> causing the
2009 Jan 07
2
[LLVMdev] Possible bug in the ARM backend?
Hi Evan,
Thanks for your feedback!
2009/1/7 Evan Cheng <evan.cheng at apple.com>:
>
> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>
>
> As you can see, PrologEpilogInserter has inserted at the beginning
> of the function some code for manipulation of the frame pointer and
> this inserted code uses the LR register.
> As far as I understand,
2018 Apr 09
2
How to get the case value from Machine Instruction
Hi, guys
I am interesting about how to get the switch case value form the Machine Instruction.
I know the switch will be converted to jump-table in the Machine Instruction.
And in the phase CodeGen , the case-value of SwitchInst can get esasly.
but it seems no case -value in Machine Instruction.
The MI as follows:
Frame Objects:
fi#0: size=1, align=0, at location [SP]
fi#1: size=4,
2018 Apr 09
0
How to get the case value from Machine Instruction
Some glitch in the emailer? I have received this message 3 times in a row!?
I think that by the time it gets as far as MI-level there is no reversible
method of determining the 'case' label at all. The reason I say this, is
that I have often seen optimisations that coalesce groups of values into
interesting logical tests and jump-tables are completely avoided. For
example, a simple
2020 Apr 07
2
[ARM] Register pressure with -mthumb forces register reload before each call
If I'm understanding what's going on in this test correctly, what's happening is:
* ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize
* In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6)
* The function has three arguments, so those three plus the register we need to hold the
2018 Apr 10
1
How to get the case value from Machine Instruction
Thanks for your help.
Is there possible I can get the realily case value form the MI?
For the case in https://bugs.llvm.org/show_bug.cgi?id=34902.
as follows.
#############################
* GCC v7.1 generated assembly
#############################
** Options: -Os -marm -march=armv7-a
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
sub
2017 Feb 13
2
ARM Backend: Emit conditional move
Hi,
I'm trying to emit a conditional move in the ARM backend for a custom
intrinsic. Basically, I want to emit the following the following
instruction sequence:
cmp r0, r1
moveq r2, #1
To implement this, I first emit a compare instruction and then I'm
trying to emit the conditional move, which is failing.
BuildMI(&MBB, DL, TII->get(ARM::CMPrr))
2012 Sep 18
2
[LLVMdev] liveness assertion problem in llc
Hi,
I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from