Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] Bogus X86-64 Patterns"
2007 Dec 13
0
[LLVMdev] Bogus X86-64 Patterns
On Dec 12, 2007, at 2:10 PM, David Greene wrote:
> Tracking down a problem with one of our benchmark codes, we've
> discovered that
> some of the patterns in X86InstrX86-64.td are wrong. Specifically:
>
> def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins
> i64mem:$src),
> "mov{d|q}\t{$src, $dst|$dst, $src}",
>
2012 Jul 26
2
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
On Jul 26, 2012, at 10:28 AM, dag at cray.com wrote:
> Jakob Stoklund Olesen <jolesen at apple.com> writes:
>
>>> What happens if the result of the above pattern using COPY_TO_REGCLASS
>>> is spilled? Will we get a 64-bit store or a 128-bit store?
>>
>> This behavior isn't affected by the change. FR64 registers are spilled
>> with 64-bit
2012 Jul 26
2
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote:
> Jakob Stoklund Olesen <jolesen at apple.com> writes:
>
>> As far as I can tell, all sub-register operations involving sub_ss and
>> sub_sd can simply be replaced with COPY_TO_REGCLASS:
>>
>> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)),
>> (VMOVSDrr VR128:$src1,
2012 Jul 26
2
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
All,
I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them.
These sub-registers are special, they are only mentioned here:
let CompositeIndices = [(sub_ss), (sub_sd)] in {
def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>;
def
2009 Apr 28
1
[LLVMdev] Register class intersection
When the coalescer is run with -join-cross-class-copies it needs to
determine the register class of the joined virtual registers. The new
register class must be compatible with both old register classes.
The current implementation chooses the register class with the larger
spill size, or the less populous class. This works with the current
targets, but it can produce illegal machine code
2009 Apr 30
6
[LLVMdev] RFC: AVX Pattern Specification [LONG]
Here's the big RFC.
A I've gone through and designed patterns for AVX, I quickly realized that the
existing SSE pattern specification, while functional, is less than ideal in
terms of maintenance. In particular, a number of nearly-identical patterns
are specified all over for nearly-identical instructions. For example:
let Constraints = "$src1 = $dst" in {
multiclass
2008 Nov 17
0
[LLVMdev] Patterns with Multiple Stores
On Monday 17 November 2008 14:28, David Greene wrote:
> I want to write a pattern that looks something like this:
>
> def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst),
> (MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri (VR128:$src,
> (MOVSDmr addr:$dst, FR64:$src))), imm:3)
>
> So I want to convert an unaligned vector store to a scalar store, a
2012 Jul 26
0
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
Jakob Stoklund Olesen <jolesen at apple.com> writes:
>> What happens if the result of the above pattern using COPY_TO_REGCLASS
>> is spilled? Will we get a 64-bit store or a 128-bit store?
>
> This behavior isn't affected by the change. FR64 registers are spilled
> with 64-bit stores, and VR128 registers are spilled with 128-bit
> stores.
>
> When the
2012 Jul 26
0
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
Jakob Stoklund Olesen <jolesen at apple.com> writes:
> These sub-registers are special, they are only mentioned here:
>
> let CompositeIndices = [(sub_ss), (sub_sd)] in {
> def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>;
> def XMM1: Register<"xmm1">, DwarfRegNum<[18, 22, 22]>;
> ...
I'm confused. Below you
2008 Nov 18
1
[LLVMdev] Patterns with Multiple Stores
On Nov 17, 2008, at 3:50 PM, David Greene wrote:
> On Monday 17 November 2008 14:28, David Greene wrote:
>> I want to write a pattern that looks something like this:
>>
>> def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst),
>> (MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri
>> (VR128:$src,
>> (MOVSDmr addr:$dst, FR64:$src))),
2008 Nov 17
2
[LLVMdev] Patterns with Multiple Stores
I want to write a pattern that looks something like this:
def : Pat<(unalignedstore (v2f64 VR128:$src), addr:$dst),
(MOVSDmr ADD64ri8(addr:$dst, imm:8), ( SHUFPDrri (VR128:$src,
(MOVSDmr addr:$dst, FR64:$src))), imm:3)
So I want to convert an unaligned vector store to a scalar store, a shuffle
and a scalar store.
There are several question I have:
- Is the imm:3 syntax
2012 Jul 26
0
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
Jakob Stoklund Olesen <jolesen at apple.com> writes:
>> If the 128-bit register is not ever used as a 128-bit register,
>> shouldn't the coalescer pick the 64- or 32-bit register?
>
> That optimization is not currently implemented for sub-registers. For
> example, if you create a GR64 virtual register and only ever use the
> sub_32bit sub-register, it would be
2013 May 20
2
[LLVMdev] VCOMISS instruction in X86
Hi,
I'm looking at scalar and packed instructions in X86.
The instruction VCOMISS is scalar. May I remove SSEPackedSingle/SSEPackedDouble domain from it?
defm VUCOMISS : sse12_ord_cmp<0x2E, FR32, X86cmp, f32, f32mem, loadf32,
"ucomiss", SSEPackedSingle>, TB, VEX, VEX_LIG;
defm VUCOMISD : sse12_ord_cmp<0x2E, FR64, X86cmp, f64,
2011 Sep 01
0
[LLVMdev] AVX spill alignment
On Aug 25, 2011, at 4:17 PM, Cameron McInally wrote:
> Hey guys,
>
> Are spills/reloads of AVX registers using aligned stores/loads?
Yes.
> I can't
> seem to find the code that aligns the stack slots to 32-bytes. Could
> someone point me in the right direction?
The register class has 256-bit spill alignment:
def VR256 : RegisterClass<"X86", [v32i8, v16i16,
2009 Mar 24
0
[LLVMdev] Reducing .td redundancy
On Mar 23, 2009, at 5:56 PM, David Greene wrote:
> Is it legal to do something like a !strconcat on a non-string
> entity? That
> is, is there some operation that will let me do this (replace
> SOME_CONCAT with
> an appropriate operator):
I don't get it, can you try a simpler example on me? :)
-Chris
>
>
> (WARNING! Hacked-up tablegen ahead!)
>
>
2009 Mar 24
2
[LLVMdev] Reducing .td redundancy
Is it legal to do something like a !strconcat on a non-string entity? That
is, is there some operation that will let me do this (replace SOME_CONCAT with
an appropriate operator):
(WARNING! Hacked-up tablegen ahead!)
multiclass sse_fp_binop_bitwise_rm<bits<8> opc, string OpcodeStr,
SDNode OpNode> {
// Vector operation emulating scalar (fp)
2009 Jul 09
0
[LLVMdev] Wrong encoding of movd on x64
On Thu, Jul 9, 2009 at 8:44 AM, Nicolas Capens<nicolas at capens.net> wrote:
> I believe I’ve found a bug in the encoding of the movd instruction on x64.
> Here’s some IR code to reproduce it:
[snip
> Note the last movq. What was probably intended to be generated was “movd
> ecx, mm0”. LLVM mistakenly sets the ‘wide’ bit of the REX prefix to 1,
> turning movd into movq. Also,
2011 Sep 01
1
[LLVMdev] AVX spill alignment
Ah, thanks. That seems easy enough.
Sorry to be pedantic, but does that snippet also handle cases where the
frame pointer, %rbp, needs to be 32-byte aligned when dynamic allocas are
present?
I've looked at the ABI, but I don't see any guarantees about 32-byte frame
alignment for AVX. That can be trouble when spill slots are based off of the
frame pointer, not the stack pointer. Please
2018 Feb 01
1
Intrinsic pattern matching
Hello,
I have a problem with pattern matching on intrinsics.
I have following code in IntrinsicsX86.td:
```
let TargetPrefix = "x86" in { // All intrinsics start with "llvm.x86.".
def int_x86_mpx_bndmk:
Intrinsic<[llvm_x86bnd_ty], [llvm_ptr_ty, llvm_i64_ty], []>;
}
```
And following instruction that is generated when @llvm.x86.mpx.bndmk is
used in code:
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
On Thu, Jan 14, 2016 at 6:05 AM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 1/13/2016 4:47 PM, Phil Tomson wrote:
>
>>
>> First off, I got this idea from the LLVM Cookbook chapter 8: Writing an
>> LLVM Backend: Lowering to multiple instructions. (now I'm having my
>> doubts as to whether this is the right approach)
>>
>
>