This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Refactor getMemBasePlusOffset & getObjectPtrOffset to accept a TypeSize
ClosedPublic

Authored by kmclaughlin on Aug 4 2020, 9:43 AM.

Details

Summary

Changes the Offset arguments to both functions from int64_t to TypeSize
& updates all uses of the functions to create the offset using TypeSize::Fixed()

Diff Detail

Event Timeline

kmclaughlin created this revision.Aug 4 2020, 9:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 4 2020, 9:43 AM
kmclaughlin requested review of this revision.Aug 4 2020, 9:43 AM
efriedma added inline comments.Aug 4 2020, 12:40 PM
llvm/include/llvm/CodeGen/SelectionDAG.h
884

Implicit sign-conversion?

kmclaughlin retitled this revision from [CodeGen] Refactor getMemBasePlusOffset to accept a TypeSize to [CodeGen] Refactor getMemBasePlusOffset & getObjectPtrOffset to accept a TypeSize.
kmclaughlin edited the summary of this revision. (Show Details)
  • Additionally refactored getObjectPtrOffset to accept a TypeSize as the Offset argument
efriedma accepted this revision.Aug 5 2020, 1:39 PM

LGTM

This revision is now accepted and ready to land.Aug 5 2020, 1:39 PM

This will cause compilation failures in our downstream fork. Is there any reason for replacing the integer overload instead of adding a TypeSize overload?
I think adding TypeSize::Fixed( to all call sites is not ideal since it's overly verbose and also confusing since it's an offset and not a type size.
It would have also been nice to add a motivation for the change in the commit message rather than just explaining what's changing.

This will cause compilation failures in our downstream fork. Is there any reason for replacing the integer overload instead of adding a TypeSize overload?
I think adding TypeSize::Fixed( to all call sites is not ideal since it's overly verbose and also confusing since it's an offset and not a type size.
It would have also been nice to add a motivation for the change in the commit message rather than just explaining what's changing.

Hi @arichardson, there were a couple of reasons for replacing the integer overload. We wanted to avoid introducing another overloaded function and instead ensure that it is clear to the caller that there is a possibility the offset could be scalable. Additionally, it is possible to cast from TypeSize -> uint64_t, so removing the integer overload helps to avoid cases in the future where new code accidentally introduces a cast. As more support is added for scalable vectors, there will be many more cases where scalable offsets are required.