This is an archive of the discontinued LLVM Phabricator instance.

Don't pass the code model to MC
ClosedPublic

Authored by rafael on Aug 2 2017, 10:08 AM.

Details

Summary

I was surprised to see the code model being passed to MC. After all, it assembles code, it doesn't create it.

The one place it is used is in the expansion of .cfi directives to handle .eh_frame being more that 2gb away from the code.

As far as I can tell, gnu assembler doesn't even have an option to enable this. Compiling a c file with gcc -mcmodel=large produces a regular looking .eh_frame. This is probably because in practice linker parse and recreate .eh_frames.

In llvm this is used because the JIT can place the code and .eh_frame very far apart. Ideally we would fix the jit and delete this option. This is hard.

Apart from confusion another problem with the current interface is that most callers pass CodeModel::Default, which is bad since MC has no way to map it to the target default if it actually needed to.

This patch then replaces the argument with a boolean with a default value. The vast majority of users don't ever need to look at it. In fact, only CodeGen and llvm-mc use it and llvm-mc just to enable more testing.

Diff Detail

Event Timeline

rafael created this revision.Aug 2 2017, 10:08 AM
davide accepted this revision.Aug 2 2017, 11:36 AM

LGTM. Excellent catch Rafael. I find amusing in retrospective we all looked at this code for years without noticing.

This revision is now accepted and ready to land.Aug 2 2017, 11:36 AM
rafael closed this revision.Aug 2 2017, 1:37 PM
lliu0 added a subscriber: lliu0.Jul 30 2018, 2:04 AM

Hi Rafael,

This change caused a regression with -mcmodel=kernel. In several places of lib/MC/MCObjectFileInfo.cpp, the logic changed from
(CMModel == CodeModel::Small || CMModel == CodeModel::Medium)
to
(!CMModel == CodeModel::Large)
which changes the behavior of CodeModel::Kernel case.

While I do agree that we shouldn't pass CodeModel command line option to llvm-mc, but in MCObjectFileInfo::InitMCObjectFileInfo, it looks that we still need a full CodeModel parameter to generate different x86_64 exception table encodings for different code models.

I can start a review for this if you agree.

Thanks,
Lei