This is an archive of the discontinued LLVM Phabricator instance.

[IR][PatternMatch] m_APInt(): allow undef elements.
AbandonedPublic

Authored by lebedev.ri on Jun 9 2018, 6:26 AM.

Details

Summary

Allows to match more splatted vectors with integer constants,
with some elements being undef.
This deficiency was noticed during D47980.

This does not propagate undef elements, that would require
returning not the splatted APInt, but the vector itself,
which would require major changes on every callsite.

Later, i suppose some deduplication with api_pred_ty may be wanted.

Thoughts?

Diff Detail

Repository
rL LLVM

Event Timeline

lebedev.ri created this revision.Jun 9 2018, 6:26 AM
lebedev.ri updated this revision to Diff 150628.Jun 9 2018, 7:20 AM

Rebased ontop of more tests, NFC.

Ping.
Or is it intentional for m_APInt not to do this?

spatel accepted this revision.Jun 18 2018, 10:05 AM

Ping.
Or is it intentional for m_APInt not to do this?

No, it's not intentional to bail on undef when matching. Until recently, all of the constant matchers failed with undef elements in vectors. I enhanced most of those matchers, but missed this one (and apfloat_match?).

I also made a comment in one of those patches about being careful about changing the binding code, but I was probably confusing api_pred_ty with this. That does need to be careful AFAICT because callers may capture and use a vector with undefs when they didn't mean to.

Sorry for the delay - LGTM.

include/llvm/IR/PatternMatch.h
170

typo - 'Different'

This revision is now accepted and ready to land.Jun 18 2018, 10:05 AM

Ping.
Or is it intentional for m_APInt not to do this?

No, it's not intentional to bail on undef when matching.
Until recently, all of the constant matchers failed with
undef elements in vectors. I enhanced most of those matchers,
but missed this one (and apfloat_match?).

Aha, great!

I also made a comment in one of those patches about being careful
about changing the binding code, but I was probably confusing
api_pred_ty with this. That does need to be careful AFAICT because
callers may capture and use a vector with undefs when they didn't mean to.

Sorry for the delay - LGTM.

No worries, thank you for the review!

spatel requested changes to this revision.Jun 18 2018, 11:29 AM

On 2nd thought, I confused myself. :)
This patch is potentially dangerous - although it's hard to find cases where that danger propagates.
As with the earlier undef matcher changes, we have to audit the users to make sure they are not incorrectly using the matcher to propagate a value with undefs where it's not safe.

Example:

define <3 x i8> @f(<3 x i8> %x) {
  %x1 = or <3 x i8> %x, <i8 8, i8 8, i8 8>
  %r = urem <3 x i8> <i8 7, i8 undef, i8 7>, %x1
  ret <3 x i8> %r
}

InstSimplify can't return <i8 7, i8 undef, i8 7> here because the return value of the middle element of that vector is not unbounded.

This revision now requires changes to proceed.Jun 18 2018, 11:29 AM

Would it be better to implement m_APInt_or_Undef and m_APFloat_or_Undef - explaining that the undef is only for vectors (and naturally must still contain at least one APInt).

Get that in with a couple of combines updated to use it (with thorough testing), We can then gradually audit the remaining cases.

Would it be better to implement m_APInt_or_Undef and m_APFloat_or_Undef - explaining that the undef is only for vectors (and naturally must still contain at least one APInt).

Get that in with a couple of combines updated to use it (with thorough testing), We can then gradually audit the remaining cases.

Yes. That is the road i was planning on taking.
It is unfeasible to do this in one (more or less) go.

arsenm resigned from this revision.Feb 21 2019, 5:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 21 2019, 5:55 PM
lebedev.ri abandoned this revision.Jan 25 2020, 3:09 AM