Displaying 7 results from an estimated 7 matches for "gr8_norex".
2014 Apr 22
2
[LLVMdev] where is F7 opcode for TEST instruction on X86?
...xF6>;
def TEST32mi : BinOpMI_F<"test", Xi32, X86testpat, MRM0m, 0xF6>;
def TEST64mi32 : BinOpMI_F<"test", Xi64, X86testpat, MRM0m, 0xF6>;
// When testing the result of EXTRACT_SUBREG sub_8bit_hi, make sure the
// register class is constrained to GR8_NOREX.
let isPseudo = 1 in
def TEST8ri_NOREX : I<0, Pseudo, (outs), (ins GR8_NOREX:$src,
i8imm:$mask),
"", [], IIC_BIN_NONMEM>, Sched<[WriteALU]>;
} // Defs = [EFLAGS]
def TEST8i8 : BinOpAI<0xA8, "test", Xi8 , AL,...
2013 Apr 06
0
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
...hout permission from your implementation of getLargestLegalSuperClass. This function should not allow normal GPR registers to be inflated to the GPR+CR super-class because not all registers in that class have enough bits.
X86RegisterInfo::getLargestLegalSuperClass() does something similar with the GR8_NOREX register class to work around some awkward x86 encoding issues with the 20 8-bit registers.
/jakob
2013 Apr 06
3
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
----- Original Message -----
> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
> To: "Akira Hatanaka" <ahatanak at gmail.com>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov>
> Sent: Tuesday, March 26, 2013 12:40:44 PM
> Subject: Re: [LLVMdev] [PATCH]
2013 Apr 07
1
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
...ementation of getLargestLegalSuperClass. This function
> should not allow normal GPR registers to be inflated to the GPR+CR
> super-class because not all registers in that class have enough
> bits.
>
> X86RegisterInfo::getLargestLegalSuperClass() does something similar
> with the GR8_NOREX register class to work around some awkward x86
> encoding issues with the 20 8-bit registers.
Okay, thanks! So when the RA decides to use this register inflation mechanism, it decides on both the inflation point and the deflation point at the same time? I'd like to understand this better, c...
2013 Apr 09
1
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
...r implementation of getLargestLegalSuperClass. This function should not
> allow normal GPR registers to be inflated to the GPR+CR super-class because
> not all registers in that class have enough bits.
>
> X86RegisterInfo::getLargestLegalSuperClass() does something similar with
> the GR8_NOREX register class to work around some awkward x86 encoding
> issues with the 20 8-bit registers.
>
> /jakob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130409/b009d3b9/attachment.html>
2012 Nov 05
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan,
With your bitcode file I am now able to reproduce the issue you're seeing.
It looks like this is a problem with the naive rewriting from virtregs to
physregs. It appears that the subreg field of physreg operands is ignored
post-register allocation. In your testcase %vreg11:sub32 is being rewritten
to RBX:sub32, but the :sub32 part is being quietly dropped when the
assembly is
2012 Nov 04
3
[LLVMdev] problem trying to write an LLVM register-allocation pass
My tst.bc is attached. I had to use ssh to copy it from my office
machine to my home laptop. In case that corrupts it, I also put a copy
here:
http://pages.cs.wisc.edu/~horwitz/LANG/tst.bc
I created the file like this:
clang -emit-llvm -O0 -c tst.c -o tst.bc
opt -mem2reg tst.bc > tst.mem2reg
mv tst.mem2reg tst.bc
Susan
On 11/4/2012 3:27 PM, Lang Hames wrote:
> Hi Susan,
>