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

[Michael Liao]

Ping again for comment on this proposal. - Michael

On Sun, 2012-08-26 at 02:57 -0700, Michael Liao wrote:
> 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
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits