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
