This is an archive of the discontinued LLVM Phabricator instance.

Make Value::getPointerAlignment() return an Align, not a MaybeAlign.
ClosedPublic

Authored by efriedma on May 16 2020, 6:04 PM.

Details

Summary

If we don't know anything about the alignment of a pointer, Align(1) is still correct: all pointers are at least 1-byte aligned.

The changes to Loads.cpp are messy; I'm not sure what the original intent was. It looks like the logic in question originates from D9791.

Diff Detail

Event Timeline

efriedma created this revision.May 16 2020, 6:04 PM
Herald added a project: Restricted Project. · View Herald Transcript

Everything except the Loads.cpp stuff LGTM.

llvm/lib/Analysis/Loads.cpp
31–32

As you noted, this seems wrong. I think this allows wrong results for llvm::isDereferenceableAndAlignedPointer queries. What happens if you remove this boosting?


From D9791:

I assume that pointers without explicit alignment have ABI alignment.

I think this is OK for pointers accessed by loads without specified alignment but not for "pointers" in the general sense. If you look at the AttributorAttributes.cpp change, the function there does something similar to the getBaseAlign on the left but it only does so for pointers accessed without specified alignment. (= I think I came to this conclusion for the second time.)

nikic added a subscriber: nikic.May 17 2020, 2:00 PM
efriedma updated this revision to Diff 264516.May 17 2020, 2:48 PM

Show what happens if I remove the weird special case from Loads.cpp

efriedma marked an inline comment as done.May 17 2020, 2:58 PM
efriedma added inline comments.
llvm/lib/Analysis/Loads.cpp
31–32

The simplest way to show what happens is to just post the patch, so I did that. The issue primarily involves pointers marked with the dereferenceable metadata/attribute; we used to assume they were naturally aligned, but now we don't.

Frontends adding dereferenceable attributes/metadata should also add the corresponding alignment attributes/metadata, but I'm not sure that's actually happening consistently in practice.

jdoerfert added inline comments.
llvm/lib/Analysis/Loads.cpp
31–32

I still believe the code was incorrect so I'm in favor of removing it. We might need to improve other places but that seems doable. Let's wait for a while to see if others want to chime in. (@fhahn, @lebedev.ri, @spatel, @nikic, @arsenm, @reames, @nlopes)

nikic added inline comments.May 18 2020, 12:33 AM
llvm/lib/Analysis/Loads.cpp
31–32

Agree that the current behavior is incorrect and we really need to do something about this, because it will block opaque pointers as well.

I think Eli is right though and Clang doesn't emit the necessary alignment attributes here right now, so that probably needs to be addressed first.

efriedma marked an inline comment as done.May 18 2020, 4:00 PM
efriedma added inline comments.
llvm/lib/Analysis/Loads.cpp
31–32

I think D80166 takes care of clang. I can't find any other code that needs to be updated.

efriedma marked an inline comment as done.May 19 2020, 8:23 PM
efriedma added inline comments.
llvm/lib/Analysis/Loads.cpp
31–32

Just merged D80166.

jdoerfert accepted this revision.May 19 2020, 10:38 PM

I still think this is the right thing to do and the changes are fine. LGTM. (Let's wait again a little while or until we get another person to look at this.)

Nit: Commit message should be updated. Maybe refer to the clang patch and mention the loads.cpp bug.

This revision is now accepted and ready to land.May 19 2020, 10:38 PM
nikic accepted this revision.May 20 2020, 12:35 AM

LGTM as well.

I'd suggest adding a release note suggesting frontends to make sure they emit align attributes/metadata when emitting dereferenceable attributes/metadata.

This revision was automatically updated to reflect the committed changes.