Displaying 15 results from an estimated 15 matches for "memw".
Did you mean:
mem
2012 Sep 07
0
[LLVMdev] teaching FileCheck to handle variations in order
...> * 'CHECK-PUSH:' pushes the current match position onto the stack.
> * 'CHECK-POP:' pops the top value off of the stack and uses it to set
> the current match position.
>
> The above test can now be re-written as:
>
> ; CHECK-PUSH:
> ; CHECK: memw(##a)
> ; CHECK-POP:
> ; CHECK: memw(##b)
>
> %0 = load i32* @a, align 4
> %1 = load i32* @b, align 4
>
> which handles either ordering of memory reads for 'a' and 'b'.
>
> Thoughts?
I'm not sure if I got the details of how the tests wo...
2012 Sep 07
5
[LLVMdev] teaching FileCheck to handle variations in order
Hello all,
For the hexagon target, we have a couple of tests that are failing due
to variations in the order of checked text. In these cases the ordering
is not directly relevant to the functionality being tested.
For example:
; CHECK: memw(##a)
; CHECK: memw(##b)
%0 = load i32* @a, align 4
%1 = load i32* @b, align 4
requires that the compiler emit the memory operations for 'a' and 'b' in
that order, even though the intent of the test might simply be to ensure
that each 'load' results in a memor...
2012 Sep 07
1
[LLVMdev] teaching FileCheck to handle variations in order
...9; pushes the current match position onto the stack.
>> * 'CHECK-POP:' pops the top value off of the stack and uses it to set
>> the current match position.
>>
>> The above test can now be re-written as:
>>
>> ; CHECK-PUSH:
>> ; CHECK: memw(##a)
>> ; CHECK-POP:
>> ; CHECK: memw(##b)
>>
>> %0 = load i32* @a, align 4
>> %1 = load i32* @b, align 4
>>
>> which handles either ordering of memory reads for 'a' and 'b'.
>>
>> Thoughts?
>
> I'm not...
2012 Apr 19
0
[LLVMdev] Target Dependent Hexagon Packetizer patch
...+ return Hexagon::JMP_GTUrrdnPnt_ie_nv_V4;
>> + case Hexagon::JMP_GTUrrdnNotPnt_nv_V4:
>> + return Hexagon::JMP_GTUrrdnNotPnt_ie_nv_V4;
>> +
>> + case Hexagon::TFR_FI:
>> + return Hexagon::TFR_FI_immext_V4;
>> +
>> + case Hexagon::MEMw_ADDSUBi_indexed_MEM_V4 :
>> + case Hexagon::MEMw_ADDi_indexed_MEM_V4 :
>> + case Hexagon::MEMw_SUBi_indexed_MEM_V4 :
>> + case Hexagon::MEMw_ADDr_indexed_MEM_V4 :
>> + case Hexagon::MEMw_SUBr_indexed_MEM_V4 :
>> + case Hexagon::MEMw_ANDr_indexed_MEM_V4 :...
2012 Sep 10
3
[LLVMdev] teaching FileCheck to handle variations in order
...Hello all,
>
> For the hexagon target, we have a couple of tests that are failing
> due to variations in the order of checked text. In these cases the
> ordering is not directly relevant to the functionality being tested.
>
> For example:
>
> ; CHECK: memw(##a)
> ; CHECK: memw(##b)
>
> %0 = load i32* @a, align 4
> %1 = load i32* @b, align 4
>
> requires that the compiler emit the memory operations for 'a' and
> 'b' in that order, even though the intent of the test might simply
>...
2012 Sep 07
0
[LLVMdev] teaching FileCheck to handle variations in order
...ra.org>wrote:
> Hello all,
>
> For the hexagon target, we have a couple of tests that are failing due to
> variations in the order of checked text. In these cases the ordering is not
> directly relevant to the functionality being tested.
>
> For example:
>
> ; CHECK: memw(##a)
> ; CHECK: memw(##b)
>
> %0 = load i32* @a, align 4
> %1 = load i32* @b, align 4
>
> requires that the compiler emit the memory operations for 'a' and 'b' in
> that order, even though the intent of the test might simply be to ensure
> that each 'load...
2012 Sep 10
0
[LLVMdev] teaching FileCheck to handle variations in order
...AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
Hello all,
For the hexagon target, we have a couple of tests that are failing due to variations in the order of checked text. In these cases the ordering is not directly relevant to the functionality being tested.
For example:
; CHECK: memw(##a)
; CHECK: memw(##b)
%0 = load i32* @a, align 4
%1 = load i32* @b, align 4
requires that the compiler emit the memory operations for 'a' and 'b' in that order, even though the intent of the test might simply be to ensure that each 'load' results in a memory read.
I'...
2012 Sep 13
2
[LLVMdev] teaching FileCheck to handle variations in order
...AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
Hello all,
For the hexagon target, we have a couple of tests that are failing due to variations in the order of checked text. In these cases the ordering is not directly relevant to the functionality being tested.
For example:
; CHECK: memw(##a)
; CHECK: memw(##b)
%0 = load i32* @a, align 4
%1 = load i32* @b, align 4
requires that the compiler emit the memory operations for 'a' and 'b' in that order, even though the intent of the test might simply be to ensure that each 'load' results in a memory read.
I'...
2019 Jun 30
6
[hexagon][PowerPC] code regression (sub-optimal code) on LLVM 9 when generating hardware loops, and the "llvm.uadd" intrinsic.
...ue: .LBB0_5, kind: fixup_Hexagon_B15_PCREL
// %bb.2:
{
r0 = #-100
} // encoding: [0x80,0xf3,0xdf,0x78]
.LBB0_3: // %while.body
// =>This Inner Loop Header: Depth=1
{
r3 = add(r0,#1)
r4 = memw(r2++#4)
memw(r1++#4) = r4.new
} // encoding: [0x23,0x40,0x00,0xb0,0x24,0x40,0x82,0x9b,0x08,0xd2,0xa1,0xab]
{
p0 = cmp.gtu(r0,r3); if (!p0.new) jump:t .LBB0_3
r0 = r3
} // encoding: [A,0x63'A',0x40'A',0x15'A'...
2012 Sep 13
0
[LLVMdev] teaching FileCheck to handle variations in order
...rote:****
>
> Hello all,
>
> For the hexagon target, we have a couple of tests that are failing due to
> variations in the order of checked text. In these cases the ordering is not
> directly relevant to the functionality being tested.
>
> For example:****
>
> ; CHECK: memw(##a)
> ; CHECK: memw(##b)
>
> %0 = load i32* @a, align 4
> %1 = load i32* @b, align 4****
>
> requires that the compiler emit the memory operations for 'a' and 'b' in
> that order, even though the intent of the test might simply be to ensure
> that each '...
2016 Feb 01
2
[Hexagon] Failure to disassemble some new-value instructions
...e does the requirement come from? Maybe I overlooked it, but I do not see it in the Hexagon V5/V55 Programmer’s Reference Manual.
One instruction packet I have encountered in the wild that triggers this failure is:
10: e0 7e df 78 78df7ee0 { r0 = #-9
14: 01 40 91 91 91914001 r1 = memw(r17 + #0)
18: 10 e1 03 25 2503e110 if (cmp.gtu(r1.new, #1)) jump:t 0x30 }
Removing the requirement seems to work fine (see attached patch).
Cheers,
Ralf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hexagon-new-value.patch
Type: application/octet-st...
2019 Jul 01
0
[hexagon][PowerPC] code regression (sub-optimal code) on LLVM 9 when generating hardware loops, and the "llvm.uadd" intrinsic.
...[0x80,0xf3,0xdf,0x78]
.LBB0_3: // %while.body
// =>This Inner Loop Header: Depth=1
{
r3 = add(r0,#1)
r4 = memw(r2++#4)
memw(r1++#4) = r4.new
} // encoding: [0x23,0x40,0x00,0xb0,0x24,0x40,0x82,0x9b,0x08,0xd2,0xa1,0xab]
{
p0 = cmp.gtu(r0,...
2011 Dec 05
0
[LLVMdev] RFC: Machine Instruction Bundle
...instructions in a bundle read values defined outside the bundle. This is a swap implemented as a parallel copy bundle:
{
R2 = R3;
R3 = R2;
}
However, even VLIW targets like Hexagon can read values defined inside the same bundle:
{
P0 = cmp.eq(R2,#4)
if (!P0) R5 = #5
if (P0.new) R3 = memw(R4)
}
This Hexagon bundle reads both the P0 predicate register defined inside the bundle (P0.new) and the value defined outside the bundle (!P0). We need to support this.
I propose that we add a new MachineOperand flag, IsInternalRead, to represent this. The flag will mean "This operand is...
2012 Apr 26
2
[LLVMdev] MemRefs in a Load Instruction
...zable".
Is there no way to preserve or attach MemRefs to the LDriw instructions
generated by way of a pattern in the InstrInfo.td file ? FWIW, the LDriw
instruction is as show here.
let isPredicable = 1 in
def LDriw : LDInst<(outs IntRegs:$dst),
(ins MEMri:$addr), "$dst = memw($addr)",
[(set IntRegs:$dst, (i32 (load ADDRriS11_2:$addr)))]>;
TIA,
Pranav
Qualcomm Innovation Center, (QuIC) is a member of the Code Aurora Forum.
2011 Dec 02
18
[LLVMdev] RFC: Machine Instruction Bundle
Machine Instruction Bundle in LLVM
Hi all,
There have been quite a bit of discussions about adding machine instruction bundle to support VLIW targets. I have been pondering what the right representation should be and what kind of impact it might have on the LLVM code generator. I believe I have a fairly good plan now and would like to share with the LLVM community.
Design Criteria
1. The