This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Fix adding wrong operand value in `promoteMemRefDescriptors`.
ClosedPublic

Authored by pifon2a on Aug 4 2020, 4:35 AM.

Details

Summary

The bug was not noticed because we didn't have a lot of custom type conversions
directly to LLVM dialect.

Diff Detail

Event Timeline

pifon2a created this revision.Aug 4 2020, 4:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 4 2020, 4:35 AM
pifon2a requested review of this revision.Aug 4 2020, 4:35 AM
ftynse accepted this revision.Aug 4 2020, 4:35 AM

Thanks!

This revision is now accepted and ready to land.Aug 4 2020, 4:35 AM
This revision was landed with ongoing or failed builds.Aug 4 2020, 4:40 AM
This revision was automatically updated to reflect the committed changes.

Can you add a test please?

Can you add a test please?

It looks like it would require using TestDialect and writing a test pass from test dialect to llvm. Could there be a simpler way of testing this?

ftynse added a comment.Aug 5 2020, 9:29 AM

It looks like it would require using TestDialect and writing a test pass from test dialect to llvm. Could there be a simpler way of testing this?

How did you stumble upon this? I think this function is called when an std.call is converted, so it should be sufficient to test that an std.call to a function that takes a mix of memrefs and scalars as arguments.

It looks like it would require using TestDialect and writing a test pass from test dialect to llvm. Could there be a simpler way of testing this?

How did you stumble upon this? I think this function is called when an std.call is converted, so it should be sufficient to test that an std.call to a function that takes a mix of memrefs and scalars as arguments.

The mix of memrefs and scalars (with STD types) does not do the trick. I stumbled upon this bug when I tried to call a function that has a custom non-std type. In my case it was !tf_framework.op_kernel_context.