On Mon, Dec 2, 2013 at 11:58 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> As discussed in the PR, combiner can combine e.g. unaligned integral > load (e.g. TImode) together with some SSE instruction that requires aligned > load, but doesn't actually check it. For AVX, most of the instructions > actually allow unaligned operands, except for a few vmov* instructions where > the pattern typically handle the misaligned mems through misaligned_operand > checks, and some nontemporal move insns that have UNSPECs that should > prevent combination. The following patch attempts to solve this by > rejecting combining of unaligned memory loads/stores into SSE insns that > don't allow it. I've added ssememalign attribute for that, but actually > only later on realized that even for the insns which load/store < 16 byte > memory values if strict alignment checking isn't turned on in hw, the > arguments don't have to be aligned at all, so perhaps instead of > ssememalign in bits all we could have is a boolean attribute whether > insn requires for pre-AVX memory operands to be as aligned as their mode, or > not (with default that it does require that). I think that we should only prevent invalid compiler transformations, so the proposed approach is correct. In the attached example, the data is properly aligned, but compiler transforms correct program to an invalid one. The code, created with the patched compiler is valid, even if someone enables "trap on unaligned" setting. When "trap on unaligned" is activated, some program should not trap in different way due to compiler transformations. The optimized and unoptimized code should run (and trap) in the same way. However, I don't think ix86_expand_special_args_builtin is needed. It is the duty of the programmer to pass properly aligned address to these builtins. The compiler shouldn't magically "fix" invalid code, in the same way as it shouldn't "break" valid code as in the case above. Uros.
