Page MenuHomePhabricator

[SVE][CodeGen] Legalisation of unpredicated load instructions

Authored by kmclaughlin on Jun 29 2020, 10:47 AM.



When splitting a load of a scalable type, the new address is
calculated in SplitVecRes_LOAD using a vscale and an add instruction.

This patch also adds a DAG combiner fold to visitADD for vscale:

  • Fold (add (vscale(C0)), (vscale(C1))) to (add (vscale(C0 + C1)))

Diff Detail

Event Timeline

kmclaughlin created this revision.Jun 29 2020, 10:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 29 2020, 10:47 AM
kmclaughlin marked an inline comment as done.Jun 29 2020, 10:50 AM
kmclaughlin added inline comments.

Where LoVT is not scalable we update the PointerInfo with the offset, IncrementSize. For scalable types I've just reused LD->getPointerInfo() for now; I'm not entirely sure how best to handle the PointerInfo for scalable vectors as MachinePointerInfo currently has no knowledge of scaled offsets.

Please split the addressing mode improvements off into a separate patch from the legalization change.


BytesIncrement doesn't need to be declared out here?




You can get an "empty" MachinePointerInfo. Something like MachinePointerInfo(LD->getPointerInfo()->getAddrSpace());

efriedma added inline comments.Jun 29 2020, 11:16 AM

Is there some reason to expect the two integers have the same width?

kmclaughlin edited the summary of this revision. (Show Details)
  • Split the addressing mode changes into a separate patch (D82893)
  • Changed MPI to MachinePointerInfo(LD->getPointerInfo()->getAddrSpace()) in SplitVecRes_LOAD
  • Use getFixedSize when creating the APInt in SplitVecRes_LOAD
kmclaughlin marked 5 inline comments as done.Jun 30 2020, 10:54 AM
kmclaughlin added inline comments.

I thought we could expect that the integers will have the same width here, since we're explicitly checking the opcodes used in the expression. I would have thought if the integers had different widths that the expression would also include a sign/zero extend or a truncate somewhere?


Thanks for the suggestion on this!

kmclaughlin marked an inline comment as done and an inline comment as not done.Jun 30 2020, 10:55 AM
efriedma added inline comments.Jun 30 2020, 12:21 PM

Both operands of an add have the same type as the result. Not sure that says anything about the operands of the vscale operations: we don't enforce any rule there. If it's supposed to be the same as the result type, probably SelectionDAG::getNode() should check that.

  • Use sextOrTrunc in getVScale() to ensure that MulImm matches the return type of the vscale
  • Add an assertion to getNode() which checks that the operand and return types of vscale match
david-arm accepted this revision.Jul 2 2020, 2:23 AM


This revision is now accepted and ready to land.Jul 2 2020, 2:23 AM
This revision was automatically updated to reflect the committed changes.

Thanks for reviewing this change, @efriedma & @david-arm!