This is an archive of the discontinued LLVM Phabricator instance.

[TargetInfo][LangOpts] Refactor target info and language options adjustment.
Needs ReviewPublic

Authored by azabaznov on Sep 19 2021, 7:02 AM.

Details

Summary
  • Function CreateTargetInfo() has an access to language options which makes target immutable after creation without modification of language options themselves. Target specific hook TargetInfo::adjustAccordingToLangOpts() can be used if such modification depends on certain target.
  • Introduce LangOptions::adjustAccordingToTI() to apply changes to language options based on target info (also without modification of target info). This also involves adding of some hooks (hasAtomics() / hasAltivec() as this options are used in PPC and WebAssembly in original TargetInfo::adjust()) which potentially can be reused.
  • Validation of OpenCL target is in CreateTargetInfo() as language options are available at that point.

Diff Detail

Event Timeline

azabaznov created this revision.Sep 19 2021, 7:02 AM
azabaznov requested review of this revision.Sep 19 2021, 7:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 19 2021, 7:02 AM

Just to elaborate on the problem that is being solved. We have ended up with cycling dependencies between LangOptions and TargetInfo i.e. some language options became dependent on the target and vice versa.

The quick solution has always been to mutate the target after its creation even though it has been intended to be immutable. While mutating the target some language options are being modified too.

So the approach suggested here eliminates this design flaw by adding a special member to LangOptions to allow resetting the options after the target has been created based on the property of the target.

The approach seems reasonable to me and there are probably not so many good alternatives. In the past, we have discussed that adjusting target settings can be eliminated by adding a special triple component for OpenCL. However, it serves a similar purpose as suggested here but seems like a larger conceptual change and some redundancy too. I am also not sure whether it is going to fit the needs for OpenCL 3 features and also use cases from all other targets...

I would suggest writing an RFC into cfe-dev about this and see if there are any other opinions.

Thanks for looking into this long design issue.