Add -Z small-data-threshold

[paulmenage]

This flag allows specifying the threshold size above which LLVM should not consider placing small objects in a .sdata or .sbss section.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @b-naber (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[paulmenage]

This is a more targeted version of what I was trying to achieve with #116555 (which would add -Z llvm-module-flag to enable the same goal on RISCV).

[b-naber]

Sorry for the late reply. I think this needs an MCP before it can be merged.

[bors]

☔ The latest upstream changes (presumably #118178) made this pull request unmergeable. Please resolve the merge conflicts.

[b-naber]

This could be merged now. Can you rebase?

[paulmenage]

There's still some lack of clarity on the MCP zulip stream whether this is the right way to solve the problem, versus a target feature. I'll push the rebase but it's probably best to not merge it yet.

[paulmenage]

OK, the conclusion on the zulip chat appeared to be that a target feature wasn't the right approach, so I think this is ready.

[apiraino]

@b-naber can you r+? If I understand this patch is ripe for merging. thanks.

[compiler-errors]

r? compiler-errors @bors r+

[bors]

📌 Commit a618f74 has been approved by compiler-errors

It is now in the queue for this repository.

[klensy]

Can this emit (at least) warn if flag used with arch that isn't supported?

[compiler-errors]

Funny because I was going to ask the same thing, but then I removed it. Given that someone else cares about the same thing, let's implement that warning then.

@bors r-

[paulmenage]

Where would be the most appropriate place to put that check?

[paulmenage]

Is there a way to issue a warning if a flag's value isn't used? Given the way LLVM supports small-data thresholds in two completely different ways (arg versus module flag) we'd be duplicating the arch checks if we put a warning at the top level. If we could check after the build that the flag had been used that would be less fragile.