This is an archive of the discontinued LLVM Phabricator instance.

TableGen/GlobalISel: Partially handle immAllOnesV/immAllZerosV
ClosedPublic

Authored by arsenm on Aug 4 2020, 5:39 AM.

Details

Summary

These should really match either G_BUILD_VECTOR or
G_BUILD_VECTOR_TRUNC, but there doesn't seem to be an existing
mechanism for matching alternative opcodes. There is GIM_SwitchOpcode,
but it seems to assume it's oly only used for matcher optimization.

I could also omit any opcode check and rely on the matcher directly
checking the opcode, but the table optimizer currently assumes there
has to be an opcode check.

Also doesn't try to handle undef elements like the DAG version.

Diff Detail

Event Timeline

arsenm created this revision.Aug 4 2020, 5:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 4 2020, 5:39 AM
arsenm requested review of this revision.Aug 4 2020, 5:39 AM

Should we just have a G_SPLAT/G_BROADCAST opcode that we can canonicalize to? I find the 3 different representations annoying to deal with.

Should we just have a G_SPLAT/G_BROADCAST opcode that we can canonicalize to? I find the 3 different representations annoying to deal with.

I count 2, not sure what the 3rd would be. I've always thought that vector constants should be legal in the DAG, but the prevailing opinion seemed to be that a build_vector of constants is somehow better

I was thinking of the in-reg vector splat with a shuffle. LGTM anyway.

aemerson accepted this revision.Aug 4 2020, 2:56 PM
This revision is now accepted and ready to land.Aug 4 2020, 2:56 PM
foad added a subscriber: foad.Aug 6 2020, 2:12 AM

I've always thought that vector constants should be legal in the DAG

Me too.