Opened 7 months ago

Last modified 11 days ago

#8300 new feature request

split-objs doesn't split on LLVM

Reported by: rwbarton Owned by:
Priority: normal Milestone:
Component: Compiler (LLVM) Version: 7.7
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Moderate (less than a day)
Test Case: Blocked By:
Blocking: Related Tickets:

Description

-split-objs is allowed with -fllvm, but it doesn't really do anything. E.g. in my perf-llvm build I have a libHSbase-4.7.0.0.a with Applicative__1.o, Arrow__1.o etc.

Change History (3)

comment:1 Changed 7 months ago by rwbarton

Couldn't we implement this, as well as tables-next-to-code, by telling LLVM to put each symbol (table or code) in its own section and then using a linker script to slice and dice the symbols into object files as desired?

(To clarify, I know that tables-next-to-code works with LLVM, I'm just suggesting an alternate implementation that might be less hackish.)

Last edited 7 months ago by rwbarton (previous) (diff)

comment:2 Changed 7 months ago by rwbarton

Hmm, I see 1f9ca81cff59ed6c0078437a992f40c13d2667c7 from Nov 2011 is apparently supposed to implement this, but it doesn't seem to work any more, if it ever did.

comment:3 Changed 11 days ago by ezyang

  • Difficulty changed from Unknown to Moderate (less than a day)

The reason is the splitter needs 'split markers' (stg_split_marker) to know where to split, and at the moment, these markers are only emitted by the native backend. However, I imagine it would not be too difficult to teach the LLVM backend how to do it. You'd have another barrier, however; the splitter needs to be taught how to read LLVM code, in much the same way it needs to be taught how to read code for different architectures.

Note: See TracTickets for help on using tickets.