This is an archive of the discontinued LLVM Phabricator instance.

[X86] EltsFromConsecutiveLoads - detect split loads without a common load base (PR32940)
AbandonedPublic

Authored by RKSimon on Jun 11 2017, 3:54 AM.

Details

Summary

As discussed on PR32940, we fail to merge some vector loads as the individual scalar loads have been split (typically for i64 -> i32 legalization on 32-bit targets) which results in not all the loads being offset from the original base.

This patch fixes this by checking to see if the load is consecutive to any previous consecutive load, and not just the first 'base' load.

Diff Detail

Repository
rL LLVM

Event Timeline

RKSimon created this revision.Jun 11 2017, 3:54 AM
niravd edited edge metadata.Jun 12 2017, 6:18 AM

It looks like this is really an issue of "areNonVolatileConsecutiveLoads" not being clever enough. BaseIndexOffset in DAGCombiner should do better. I'd favor moving BaseIndexOffset out of the DAG Combiner and rewriting areNonVolatileConsecutiveLoads off of that.

Also, popping up a level, do you know if there's a reason why this is done as an X86-specific pass? It seems entirely generic.

Also, popping up a level, do you know if there's a reason why this is done as an X86-specific pass? It seems entirely generic.

It's done here as we're trying to match various x86 specific load patterns - basic consecutive loads, 'masked' loads with undef/zeros that get blended out, loads with all upper vector elements set to zero. I'm also hoping to add broadcast/vector_broadcast soon (possibly ZERO_EXTEND_VECTOR_INREG as well).

It looks like this is really an issue of "areNonVolatileConsecutiveLoads" not being clever enough. BaseIndexOffset in DAGCombiner should do better. I'd favor moving BaseIndexOffset out of the DAG Combiner and rewriting areNonVolatileConsecutiveLoads off of that.

Are you suggesting we move BaseIndexOffset to a header so that it can be used in SelectionDAG as well or move all uses from DAGCombiner.cpp into SelectionDAG.cpp (load combines, store merge, neighbour chains etc.)?

I'm suggesting we move BaseIndexOffset into SelectionDAG so it can be called there as well.

Are you suggesting we move BaseIndexOffset to a header so that it can be used in SelectionDAG as well or move all uses from DAGCombiner.cpp into SelectionDAG.cpp (load combines, store merge, neighbour chains etc.)?

RKSimon abandoned this revision.Jun 23 2017, 11:37 AM

D34472 is providing a more general solution