This is an archive of the discontinued LLVM Phabricator instance.

[clang] Deprecate uses of GlobalObject::getAlignment
Needs ReviewPublic

Authored by gchatelet on Jan 24 2023, 5:20 AM.

Details

Reviewers
courbet
Summary

This remove the last uses of GlobalObject::getAlignment and marks it as deprecated.

Diff Detail

Event Timeline

gchatelet created this revision.Jan 24 2023, 5:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 24 2023, 5:20 AM
gchatelet requested review of this revision.Jan 24 2023, 5:20 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJan 24 2023, 5:20 AM
courbet added inline comments.Jan 24 2023, 5:56 AM
clang/include/clang/AST/CharUnits.h
73

Maybe*

clang/lib/CodeGen/CGObjCMac.cpp
1991

I'm wondering whetehr we could just do away with this conversion and store a MaybeAlign in GlobalValue instead.

The only uses of Address::getAlign() is to creata another Address or do Address::getAlign()->getAsAlign()

tra added a subscriber: tra.Jan 24 2023, 10:31 AM
tra added inline comments.
clang/lib/CodeGen/CGCUDANV.cpp
491

This appears to be a change in behavior. AFAICT, previously used Var->getAlignment() could return alignment value or 0. Now it's value or 1.

Is it intentional?

gchatelet added inline comments.Jan 24 2023, 11:21 AM
clang/lib/CodeGen/CGCUDANV.cpp
491

The previous statement was constructing an llvm::Align from a value, and llvm::Align asserts when the provided value is 0. This means that it is undefined to pass the value 0.

As far as LoadInst is concerned it can only accept valid alignments (i.e., powers of two => non zero).

So you're right that it is not strictly NFC and that *Var->getAlign()would be a more rigorous transformation but I think that converting the 0 value to 1 moves us from UB to semantically valid code.

I don't feel strongly about it though and I'm fine changing this to *Var->getAlign() to keep this patch NFC. WDYT?

tra added a subscriber: yaxunl.Jan 24 2023, 12:02 PM
tra added inline comments.
clang/lib/CodeGen/CGCUDANV.cpp
491

Enforcing alignment of 1 would potentially force us to generate overly conservative one byte at a time loads/stores.
I agree that passing 0 is a wrong choice here, but 1 does not seem to be correct, either.
Unfortunately LoadInst does not have overloads accepting MaybeAlign so we need to use different LoadInst overload depending on whether alignment is specified.

NewV =  Var->getAlign().isAligned() 
  ? llvm::LoadInst(Var->getType(), ManagedVar, "ld.managed", false,  Var->getAlign().value(), I)
  : llvm::LoadInst(Var->getType(), ManagedVar, "ld.managed", false,  I);

@yaxunl -- Sam, does it make sense? This seems to be largely HIP-specific.

barannikov88 added inline comments.
clang/lib/CodeGen/CGCUDANV.cpp
491

I think it should be just Var->getAlign() to allow propagating absent alignment.
Curiously, the old code didn't assert because GlobalVariable seem to always(?) have non-empty alignment if the global had an associated VarDecl (set here, changed(?) by this patch).

barannikov88 added inline comments.Jan 24 2023, 12:15 PM
clang/lib/CodeGen/CGCUDANV.cpp
491

Unfortunately LoadInst does not have overloads accepting MaybeAlign so we need to use different LoadInst overload depending on whether alignment is specified.

That's interesting, because SelectionDAG::getLoad has many variants with MaybeAlign, but only one with Align.

gchatelet added inline comments.Jan 25 2023, 2:17 AM
clang/lib/CodeGen/CGCUDANV.cpp
491

The documentation says that LoadInst alignment is optional so indeed it should accept a MaybeAlign instead of an Align.
I'll send a patch to fix this.

Then we can indeed simply use Var->getAlign().

efriedma added inline comments.
clang/lib/CodeGen/CGCUDANV.cpp
491

Alignment is "optional" in textual IR for backward-compatibility/ease of use... but it's just a shortcut for specifying "use the ABI alignment of the value type". It isn't optional in memory. Maybe LangRef could be updated to make that a bit more clear. (See D77454.)

We should consider doing something similar for globals, but at the time, I ran out of energy to try to deal with that; backend handling for globals with unspecified alignment is weird.

yaxunl added inline comments.Jan 25 2023, 3:35 PM
clang/lib/CodeGen/CGCUDANV.cpp
491

Enforcing alignment of 1 would potentially force us to generate overly conservative one byte at a time loads/stores.
I agree that passing 0 is a wrong choice here, but 1 does not seem to be correct, either.
Unfortunately LoadInst does not have overloads accepting MaybeAlign so we need to use different LoadInst overload depending on whether alignment is specified.

NewV =  Var->getAlign().isAligned() 
  ? llvm::LoadInst(Var->getType(), ManagedVar, "ld.managed", false,  Var->getAlign().value(), I)
  : llvm::LoadInst(Var->getType(), ManagedVar, "ld.managed", false,  I);

@yaxunl -- Sam, does it make sense? This seems to be largely HIP-specific.

Thanks for reminding me about this.

If it is 0 it should have caused an assertion.

We can probably use getAlign().value() to keep the original asserting behaviour instead of silently using value 1.

arsenm added a subscriber: arsenm.Jan 25 2023, 3:43 PM
arsenm added inline comments.
clang/lib/CodeGen/CGCUDANV.cpp
491

I think MaybeAlign is ridiculous and we should just require alignments everywhere. It's never really optional, it's just hidden sometimes

Thx @efriedma for reminding me of this.
I'll update the documentation and try to give a shot at removing MaybeAlign from GlobalObject.