This is an archive of the discontinued LLVM Phabricator instance.

[CUDA][HIP] Add -Xarch_device and -Xarch_host options
ClosedPublic

Authored by yaxunl on Mar 20 2020, 12:16 PM.

Details

Summary

The argument after -Xarch_device will be added to the arguments for CUDA/HIP
device compilation and will be removed for host compilation.

The argument after -Xarch_host will be added to the arguments for CUDA/HIP
host compilation and will be removed for device compilation.

Diff Detail

Event Timeline

yaxunl created this revision.Mar 20 2020, 12:16 PM

Does it handle options with values? E.g. if I want to pass -mframe-pointer=none ? I vaguely recall the current -Xarch_* implementation had some limitations.
It may be worth adding a test for that.

yaxunl updated this revision to Diff 252024.Mar 23 2020, 7:11 AM

Add a test for passing options with value

In D76520#1934341, @tra wrote:

Does it handle options with values? E.g. if I want to pass -mframe-pointer=none ? I vaguely recall the current -Xarch_* implementation had some limitations.
It may be worth adding a test for that.

-Xarch_ works with driver options having value, e.g. -fcf-protection=branch. I added a test for that.

-mframe-pointer=none is a cc1 option. That's why it cannot be passed by -Xarch_. If it is made a driver option it can be passed.

tra added a comment.Mar 23 2020, 9:30 AM

-Xarch_ works with driver options having value, e.g. -fcf-protection=branch. I added a test for that.

-mframe-pointer=none is a cc1 option. That's why it cannot be passed by -Xarch_. If it is made a driver option it can be passed.

In other words, if we need to pass a cc1 option to a specific sub-compilation, we'll need an arch-specific -Xclang variant. Does -Xarch_foo -Xclang -Xarch_foo <foo-specific cc1 option> work with this patch? Considering that sub-compilations *are* cc1 invocations, passing cc1 options is something that would be very useful as not all cc1 options can be directly controlled from the driver level, but most driver options not directly related to the pipeline construction can be overridden by cc1 options.

In D76520#1937217, @tra wrote:

-Xarch_ works with driver options having value, e.g. -fcf-protection=branch. I added a test for that.

-mframe-pointer=none is a cc1 option. That's why it cannot be passed by -Xarch_. If it is made a driver option it can be passed.

In other words, if we need to pass a cc1 option to a specific sub-compilation, we'll need an arch-specific -Xclang variant. Does -Xarch_foo -Xclang -Xarch_foo <foo-specific cc1 option> work with this patch? Considering that sub-compilations *are* cc1 invocations, passing cc1 options is something that would be very useful as not all cc1 options can be directly controlled from the driver level, but most driver options not directly related to the pipeline construction can be overridden by cc1 options.

-Xarch_ does not work for passing -cc1 options in the beginning. This patch does not change that.

This requires some further changes about how the options after -Xarch_ are handled. I would suggest to do that in another patch.

tra added a comment.Mar 23 2020, 10:49 AM

-Xarch_ does not work for passing -cc1 options in the beginning. This patch does not change that.

This requires some further changes about how the options after -Xarch_ are handled. I would suggest to do that in another patch.

I'm OK with a separate patch.
Meanwhile we should document that it only works for driver args. Perhaps add a TODO comment in the TranslateXarchArgs describing its limitations.

yaxunl updated this revision to Diff 252105.Mar 23 2020, 11:32 AM

add TODO for fixing space separated arguments

tra accepted this revision.Mar 23 2020, 12:02 PM
This revision is now accepted and ready to land.Mar 23 2020, 12:02 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2020, 7:30 AM