This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Support big-endian systems in DenseElementsAttr (multiple word)
ClosedPublic

Authored by imaihal on May 19 2020, 11:45 PM.

Details

Summary

D78076 supports big endian in DenseElementsAttr, but does not work when
APInt has multiple words(the number of bits > 64). This patch updates
D78076 to support it.
This patch removed the fix in D78076 and re-implemented to support multiple words.

Diff Detail

Event Timeline

imaihal created this revision.May 19 2020, 11:45 PM
Herald added a project: Restricted Project. · View Herald Transcript
imaihal updated this revision to Diff 265407.May 20 2020, 7:23 PM

Fixed variable name to meet camelBack style

imaihal edited the summary of this revision. (Show Details)May 20 2020, 7:25 PM
imaihal edited the summary of this revision. (Show Details)May 20 2020, 7:27 PM
imaihal edited the summary of this revision. (Show Details)May 26 2020, 10:15 PM

Sorry for the delay, I've been OOO. Looks good, just a couple of comments.

mlir/lib/IR/Attributes.cpp
569–570

nit: I would spell out big endian in the function name, or at least put it in the comment above.

573

nit: Remove this newline.

573

This looks identical to below, can you extract into a helper?

Herald added a project: Restricted Project. · View Herald TranscriptJun 5 2020, 10:10 AM
Herald added a subscriber: msifontes. · View Herald Transcript

In general, I'd like to strongly discourage directly checking endian::system_endianness(), in favor of using the endian-sensitive read/write helpers from llvm/Support/Endian.h. For example, you can copy_n from an endian::ulittle64_t* to a uint64_t*. Using a distinct codepath for big-endian means more code, and that code gets less testing.

In general, I'd like to strongly discourage directly checking endian::system_endianness(), in favor of using the endian-sensitive read/write helpers from llvm/Support/Endian.h. For example, you can copy_n from an endian::ulittle64_t* to a uint64_t*. Using a distinct codepath for big-endian means more code, and that code gets less testing.

Thanks for the comments Eli! Didn't know about those. Will recommend the same in the future.

imaihal updated this revision to Diff 270022.Jun 10 2020, 7:19 PM
imaihal edited the summary of this revision. (Show Details)

Reflect reviewer's comments.

imaihal marked 4 inline comments as done.Jun 10 2020, 7:21 PM
imaihal added inline comments.
mlir/lib/IR/Attributes.cpp
573

Created getAPIntCopyParam() to calculation parameters for copying.

imaihal marked an inline comment as done.Jun 10 2020, 7:22 PM

In general, I'd like to strongly discourage directly checking endian::system_endianness(), in favor of using the endian-sensitive read/write helpers from llvm/Support/Endian.h. For example, you can copy_n from an endian::ulittle64_t* to a uint64_t*. Using a distinct codepath for big-endian means more code, and that code gets less testing.

Thanks for the comments Eli! Didn't know about those. Will recommend the same in the future.

I didn't know that. I will check it and create another patch in the future.

Can you try Eli's suggestion in this patch?

imaihal updated this revision to Diff 301941.Oct 30 2020, 10:10 AM

Use ulittle for eidian conversion.

imaihal updated this revision to Diff 302098.Oct 31 2020, 8:49 AM

Updated comments and inserted assert.

imaihal edited the summary of this revision. (Show Details)Oct 31 2020, 9:00 AM

Can you try Eli's suggestion in this patch?

@rriddle Sorry for late response. He suggested we should not check endianenss, This means we should use the same code in BE and LE machines.
However, I think redundant copy are required in LE to use the same code. So, current patch checks the endianness to avoid it.
Do you have any thought?

Hi, @rriddle, do you have any comments on this patch?

rriddle accepted this revision.Nov 17 2020, 12:19 AM
This revision is now accepted and ready to land.Nov 17 2020, 12:19 AM

Apologies for the delay. LGTM as seems we are reusing the same methods we added in the patch for parsing.

@rriddle Thanks for reviewing many times! I don't have commit access. Could you commit this patch if you don't have any other comments?