On Mon, Jan 4, 2016 at 12:21 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Sun, Jan 03, 2016 at 07:11:58PM -0800, H.J. Lu wrote:
>> --- a/gcc/config/i386/predicates.md
>> +++ b/gcc/config/i386/predicates.md
>> @@ -951,6 +951,13 @@
>>         (match_test "INTEGRAL_MODE_P (GET_MODE (op))")
>>         (match_test "op == CONSTM1_RTX (GET_MODE (op))")))
>>
>> +; Return true when OP is operand acceptable for vector memory operand.
>> +; Only AVX can have misaligned memory operand.
>> +(define_predicate "vector_memory_operand"
>> +  (and (match_operand 0 "memory_operand")
>> +       (ior (match_test "TARGET_AVX")
>> +         (match_test "MEM_ALIGN (op) >= GET_MODE_ALIGNMENT (mode)"))))
>
> Shouldn't this take into account the ssememalign attribute too?
> I mean, various instructions have some ssememalign > 8, which means they
> can't accept any alignment, but happily accept say >= 32-bit alignment
> or >= 64-bit alignment.  Though, ssememalign is an instruction attribute
> and the predicates/constraints don't have access to the current instruction.
> So maybe we need more constraints and more predicates, the ones you've added
> for ssememalign == 0 instructions, don't change anything in instructions
> with ssememalign == 8 (you've clearly changed some of them, and patch 3
> shows you've tried to partially undo it afterwards, but only the constraint,
> not the predicate, and only in one instruction), and use different
> predicates/constraints for ssememalign == {16,32,64} instructions.
>
>         Jakub

>From INSTRUCTION EXCEPTION SPECIFICATION section in Intel SDM
volume 2, only legacy SSE instructions with memory operand not
16-byte aligned get General Protection fault.  There is no need to check
1, 2, 4, 8 byte alignments. Since x86 backend has accurate constraints
and predicates for 16-byte alignment after my patches, there is no need for
ix86_legitimate_combined_insn nor ssememalign.  My followup patch will
remove them.  I have tested it without regressions.  I will submit it after my
patches have been checked in.


-- 
H.J.

Reply via email to