This is an archive of the discontinued LLVM Phabricator instance.

GlobalISel: Add alignment to LegalityQuery MMOs
ClosedPublic

Authored by arsenm on Jan 30 2019, 7:05 AM.

Details

Summary

This allows targets to specify the minimum alignment required for the
load/store.

Diff Detail

Event Timeline

arsenm created this revision.Jan 30 2019, 7:05 AM

Hi, this rule will be very useful for mips32r5 that only supports naturally aligned loads and stores.
However, could we have additional structure named TypeMemAndAlignDesc (or something more appropriate) and rule that uses this structure named legalForTypesWithMemSizeAndAlign instead of changing already existing ones.
This would leave TypePairAndMemSize and typePairAndMemSizeInSet to be used as is, since alignment is not considered on some targets/subtargets (like mips32r6). There are rules that do not take memsize into account (like LegalFor or legalForCartesianProduct).

Hi, this rule will be very useful for mips32r5 that only supports naturally aligned loads and stores.
However, could we have additional structure named TypeMemAndAlignDesc (or something more appropriate) and rule that uses this structure named legalForTypesWithMemSizeAndAlign instead of changing already existing ones.
This would leave TypePairAndMemSize and typePairAndMemSizeInSet to be used as is, since alignment is not considered on some targets/subtargets (like mips32r6). There are rules that do not take memsize into account (like LegalFor or legalForCartesianProduct).

I would think having fewer versions with all the necessary information would be better. The memory instructions are already special since they care about something besides the operand types. Also, this isn't the only addition I want to make here. I'll probably want to add the MMO flags here at some point, and wouldn't want to introduce a 3rd set of these

@dsanders does this look ok to you?

include/llvm/CodeGen/GlobalISel/LegalizerInfo.h
180

This isCompatible relation isn't commutative, so it would be good to make it clear here what it actually means for A.isCompatible(B) to be true.

@dsanders does this look ok to you?

This looks sensible to me. I agree with adding it to the existing type as most targets will want to be checking alignment here and the few that don't can just check against alignment 1.

From my side, there's just the one nit that Amara didn't already raise which is the truncation of the getAlignment() result. We should probably just store the uint64_t (and hope the optimizer is smart enough to inline it into the lambda). If we're going to do the truncate we should have an assert guard against overflow.

lib/CodeGen/GlobalISel/LegalizerInfo.cpp
428

Why the static cast?

arsenm marked an inline comment as done.Feb 7 2019, 3:55 PM

I'm not sure why the MMO alignment is uint64_t in the first place. The maximum supported alignment is 1 << 29 (which I guess when converted to bits is 1 too many for uint32)

lib/CodeGen/GlobalISel/LegalizerInfo.cpp
428

LegalizerInfo.cpp:429:10: error: non-constant-expression cannot be narrowed from type 'unsigned long long' to 'uint32_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]

MMO->getAlignment() * 8});
^~~~~~~~~~~~~~~~~~~~~~~

../lib/CodeGen/GlobalISel/LegalizerInfo.cpp:429:10: note: insert an explicit cast to silence this issue

MMO->getAlignment() * 8});
^~~~~~~~~~~~~~~~~~~~~~~
static_cast<uint32_t>( )

I'm not sure why the MMO alignment is uint64_t in the first place. The maximum supported alignment is 1 << 29 (which I guess when converted to bits is 1 too many for uint32)

Hmm, 1 << 29 is in range for both uint32_t and int32_t so it's presumably just an overly large return type. Fair enough, I think it would be good to fix the oversized return value so that people don't have to silence these warnings but that's not for this patch.

arsenm updated this revision to Diff 185897.Feb 7 2019, 5:11 PM

Add comment, make sure the maximum alignment works.

Size probably doesn't need to be 64-bits since LLT only supports 16-bits

This revision is now accepted and ready to land.Feb 14 2019, 2:15 PM
arsenm closed this revision.Feb 14 2019, 2:40 PM

r354071