This is an archive of the discontinued LLVM Phabricator instance.

X86: Remove UsesMSVCFloatingPoint from MachineModuleInfo
Needs ReviewPublic

Authored by arsenm on Apr 18 2022, 7:02 AM.

Details

Summary

This is x86 specific and only used in the AsmPrinter module pass. I
think implementing this by looking at the underlying IR types instead
of the selected instructions is a pretty horrifying implementation,
but it's still available in the AsmPrinter.

Diff Detail

Event Timeline

arsenm created this revision.Apr 18 2022, 7:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 18 2022, 7:02 AM
arsenm requested review of this revision.Apr 18 2022, 7:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 18 2022, 7:02 AM
Herald added a subscriber: wdng. · View Herald Transcript
rnk added a subscriber: mstorsjo.Apr 18 2022, 12:06 PM

This is sort of reasonable, but I feel like people might disagree so I won't go ahead and stamp it.

I feel like the existing code adheres to the philosophy that the IR will not be available after codegen, and that ISel is responsible for looking at the IR and saving all these analysis results. There's something undesirable about looking back at the IR once we reach the end of assembly emission.

On the other hand, it's also nice to not have all these long-lived predicates stashed in a side table that we then have to serialize through MIR.

I think in the end, we should land this change, but I'd like to see another +1. If people don't like this, maybe we can use X86MachineFunctionInfo.

Lastly, has anyone checked if MSVC emits _fltused on AArch64 / ARM? Maybe it's not as target-specific as it appears. +@mstorsjo

This is sort of reasonable, but I feel like people might disagree so I won't go ahead and stamp it.

I feel like the existing code adheres to the philosophy that the IR will not be available after codegen, and that ISel is responsible for looking at the IR and saving all these analysis results. There's something undesirable about looking back at the IR once we reach the end of assembly emission.

Right, but we're nowhere near that goal. There are tons of backlinks to the IR and targets looking directly at the underlying IR. There are a good number of MachineFunction predicates that look at attributes on the IR for example. Ironically I think this helps move towards the direction of cutting out the IR by making MIR serialization more obviously reliable

Lastly, has anyone checked if MSVC emits _fltused on AArch64 / ARM? Maybe it's not as target-specific as it appears. +@mstorsjo

It does seem like MSVC emits this symbol reference on those architectures too - so I guess technically we should try to emit the same there too. (I haven't heard about issues relating to this being missing, but I don't use MSVC mode as much as mingw mode either.)