> 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() ?
That wouldn't be the first time that this replacement is done.
> I'm
On 12 September 2013 12:47, Richard Biener wrote:
> Look at the -fdump-tree-vect-details, it should print what it does during
> alignment analysis. Then debug the code ...
OK, I think I got to the bottom of this. It's not the vectorizer fault
after all. Jakub was right to point out that there is
On Thu, Sep 12, 2013 at 11:59 AM, Frederic Riss wrote:
> On 12 September 2013 11:25, Richard Biener wrote:
>> You may simply hit some bug in the vectorizer. The vectorizer assumes
>> it can re-align local decls, and for the above it should use
>> known-misalignment
>> accesses. You can check w
On 12 September 2013 11:25, Richard Biener wrote:
> You may simply hit some bug in the vectorizer. The vectorizer assumes
> it can re-align local decls, and for the above it should use
> known-misalignment
> accesses. You can check with -fdump-rtl-expand-details-alias what the
> MEMs think they
On Thu, Sep 12, 2013 at 11:25:31AM +0200, Richard Biener wrote:
> On Thu, Sep 12, 2013 at 10:40 AM, Frederic Riss
> wrote:
> > Thus I'm wondering if the vectorizer makes the assumption that a
> > target must be able to load/store vectors aligned on any element size
> > boundary. If it's the case,
On Thu, Sep 12, 2013 at 10:40 AM, Frederic Riss wrote:
> Hello,
>
> I have coded SIMD support for my target, but I'm hitting some issues
> relative to alignment. I can't find any documentation or comment
> describing the assumptions that the vectorizer makes about target
> support, if it exists pl
