[llvm-commits] [RFC/PATCH] introduce 'UseSSEx' predicates

[Michael Liao]

On Fri, 2012-08-24 at 19:23 -0700, Eli Friedman wrote:
> On Fri, Aug 24, 2012 at 6:55 PM, Michael Liao <michael.liao at intel.com> wrote:
> > On Fri, 2012-08-24 at 18:14 -0700, Eli Friedman wrote:
> >> On Wed, Aug 22, 2012 at 10:27 AM, Michael Liao <michael.liao at intel.com> wrote:
> >> > Hi
> >> >
> >> > The attached patch adds several new predicates, namely UseSSE1, UseSSE2,
> >> > UseSSE3, UseSSSE3, UseSSE41, and UseSSE42.
> >> >
> >> > As the penalty of inter-mixing SSE and AVX instructions, we need prevent
> >> > SSE legacy insn from being generated except explicitly specified through
> >> > some intrinsics. For patterns both supported by both SSE and AVX, so
> >> > far, we force AVX insn will be tried first relying on AddedComplexity or
> >> > td location. It's error-prone and introduces bugs accidentally.
> >> >
> >> > 'UseSSEx' is disabled when AVX is turned on. For insns both supported by
> >> > AVX and SSE insns, we need this predicate to force VEX encoding only.
> >> >
> >> > For insns not inherited by AVX, we still use the previous predicates,
> >> > i.e. 'HasSSEx'. So far, these insns fall into the following categories:
> >> >   * SSE insns with MMX operands
> >> >   * SSE insns with GPR/mem operands only (xFENCE, PREFETCH, CLFLUSH,
> >> >     CRC, and etc.)
> >> >   * SSE4A insns.
> >> >   * MMX insns.
> >> >   * x87 insns added by SSE.
> >> >
> >> > With this patch, several inter-mixing cases are found and fixed from
> >> > regression tests.
> >>
> >> --- a/test/ExecutionEngine/MCJIT/test-common-symbols.ll
> >> +++ b/test/ExecutionEngine/MCJIT/test-common-symbols.ll
> >> @@ -1,4 +1,4 @@
> >> -; RUN: %lli -use-mcjit -O0 -disable-lazy-compilation=false %s
> >> +; RUN: %lli -use-mcjit -disable-lazy-compilation=false %s
> >>
> >>  ; The intention of this test is to verify that symbols mapped to COMMON in ELF
> >>  ; work as expected.
> >>
> >> What is the point of this change?
> >
> > So far, MCJIT cannot support the creation of '.rodata' section. This's
> > work around. I will file a bug for MCJIT.
> 
> Oh, I see...
> 
> How hard would it be to fix fast-isel so it can select vcvtsi2sdq?

Regard to the failure of MCJIT with this patch, finally I find the root
cause. Target constant rematerialization in X86 fast-isel doesn't handle
large code model correctly and create a PC-rel addressing which crashes
when the displacement is out of 32-bit immediate range. I added a simple
fix similar to large code model is handled in X86 fast-isel in
elsewhere.

The patch is revised and attached here. Not sure it's ok to commit.

Yours
- Michael

PS: the issue found in fast-isel + MCJIT is not introduced by this
patch. A simple change to
test/ExecutionEngine/MCJIT/test-common-symbols.ll could trigger that
crash.


diff --git a/test/ExecutionEngine/MCJIT/test-common-symbols.ll
b/test/ExecutionEngine/MCJIT/test-common-symbols.ll
index ac1d9ac..9fce719 100644
--- a/test/ExecutionEngine/MCJIT/test-common-symbols.ll
+++ b/test/ExecutionEngine/MCJIT/test-common-symbols.ll
@@ -37,7 +37,7 @@ entry:
   %arrayidx = getelementptr inbounds [10 x i32]* @zero_arr, i32 0, i64
%idxprom
   store i32 40, i32* %arrayidx, align 4
   %1 = load double* @zero_double, align 8
-  %cmp = fcmp olt double %1, 1.000000e+00
+  %cmp = fcmp olt double %1, 1.100000e+00
   br i1 %cmp, label %if.then, label %if.end
 
 if.then:                                          ; preds = %entry



> 
> -Eli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-introduce-UseSSEx-to-force-SSE-legacy-encoding.patch
Type: text/x-patch
Size: 50816 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120826/85eb7b19/attachment.bin>