Skip to content
  1. Aug 30, 2012
    • Michael Liao's avatar
      Introduce 'UseSSEx' to force SSE legacy encoding · bbd10792
      Michael Liao authored
      - Add 'UseSSEx' to force SSE legacy insn not being selected when AVX is
        enabled.
      
        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 supported by both
        SSE and AVX, so far, we force AVX insn will be tried first relying on
        AddedComplexity or position in td file. It's error-prone and
        introduces bugs accidentally.
      
        'UseSSEx' is disabled when AVX is turned on. For SSE insns inherited
        by AVX, we need this predicate to force VEX encoding or SSE legacy
        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.
      
      2 test cases are modified:
      
       - test/CodeGen/X86/fast-isel-x86-64.ll
         AVX code generation is different from SSE one. 'vcvtsi2sdq' cannot be
         selected by fast-isel due to complicated pattern and fast-isel
         fallback to materialize it from constant pool.
      
       - test/CodeGen/X86/widen_load-1.ll
         AVX code generation is different from SSE one after fixing SSE/AVX
         inter-mixing. Exec-domain fixing prefers 'vmovapd' instead of
         'vmovaps'.
      
      llvm-svn: 162919
      bbd10792
    • Craig Topper's avatar
      Only perform DAG combine on FMAs of legal types. · e39ad7b5
      Craig Topper authored
      llvm-svn: 162892
      e39ad7b5
    • Michael Liao's avatar
      Fix PR13727 · 3c898064
      Michael Liao authored
      - The root cause is that target constant materialization in X86 fast-isel
        creates a PC-rel addressing which may overflow 32-bit range in non-Small code
        model if .rodata section is allocated too far away from code segment in
        MCJIT, which uses Large code model so far.
      - Follow the similar logic to fix non-Small code model in fast-isel by skipping
        non-Small code model.
      
      llvm-svn: 162881
      3c898064
  2. Aug 29, 2012
  3. Aug 28, 2012
  4. Aug 27, 2012
  5. Aug 25, 2012
  6. Aug 24, 2012
  7. Aug 23, 2012
  8. Aug 22, 2012
  9. Aug 21, 2012
Loading