Auto-vectorizer and (mis-)alignment support assumptions

Frédéric RISS frederic.riss@gmail.com
Thu Sep 12 20:46:00 GMT 2013


On Thu, 2013-09-12 at 17:39 +0200, Frederic Riss wrote:
> The issue is that I am using super-block
> scheduling in sched2 and that my sched_reorder hook prioritized the
> load operation over the conditional branch that did the alignment
> check.
> 
> I'm now leaning toward a scheduler bug (or my customization thereof).
> I expect superblock scheduling to hoist instructions out of their
> original basic-block, but it seems very dangerous to move memory
> accesses this way (without speculation). 

I tracked this down to may_trap_p(). Stack pointer relative accesses are
always considered non-trapping, thus the scheduler is allowed to execute
it speculatively. The vectorizer has protected the access, but the fact
that it's stack-relative allows it to escape the protected region... I
hit this case because of extended basic-block scheduling, but I think
the problem is more general than that.

may_trap_or_fault_p() does the right thing by taking the misalignement
of stack accesses into account on STRICT_ALIGN targets. Would it be a
solution to call that instead may_trap_p() from
haifa-sched.c:may_trap_exp() ?

I'm not clear why may_trap_p() and may_trap_or_fault_p() are different
functions. When would we want to disallow a trap, but allow a
misalignment fault? 

Fred



More information about the Gcc mailing list