This is an archive of the discontinued LLVM Phabricator instance.

DAG: Fix mis-legalization of i1 zextload
AbandonedPublic

Authored by arsenm on Mar 27 2017, 9:52 AM.

Details

Reviewers
None
Summary

The bits aren't guaranteed to be zero.

Diff Detail

Event Timeline

arsenm created this revision.Mar 27 2017, 9:52 AM

Can you describe the issue you're trying to fix here in a bit more detail? As far as I know, the bits are in fact guaranteed to be zero.

Can you describe the issue you're trying to fix here in a bit more detail? As far as I know, the bits are in fact guaranteed to be zero.

i1 zextload to i32 is being legalized to AssertZext (zextload i8 to i32), so there was no and truncating to a single bit. As far as I know nothing is guaranteed about the high bits in memory of a < byte value.

It's certainly something many ABIs guarantee, so either BooleanContents models it in some way (the value for i8?) or we could do with something that does.

Can you describe the issue you're trying to fix here in a bit more detail? As far as I know, the bits are in fact guaranteed to be zero.

i1 zextload to i32 is being legalized to AssertZext (zextload i8 to i32), so there was no and truncating to a single bit. As far as I know nothing is guaranteed about the high bits in memory of a < byte value.

If an <N x i1> vector is supposed to be packed in memory, I would expect
%cast.ptr = bitcast <64 x i1> to i1*
%elt0 = load i1, i1* %cast.ptr
to do the right thing and truncate the value

We ensure that the high bits of i1 etc. in memory are zero when we lower a store... which is really all that matters. See SelectionDAGLegalize::LegalizeStoreOps.

arsenm abandoned this revision.Feb 21 2019, 6:45 PM

I think this is still broken but I lack the will to push on this further