[LLVMdev] Inline hints for *compiler clients*
Vikram S. Adve
vadve at cs.uiuc.edu
Wed Mar 15 07:20:25 PST 2006
[I've changed the subject to make this a new thread.]
While all of this makes sense to me, note that Markus and John were
asking about different situations. Markus was asking about user-
written source code. John was asking about a compiler pass or tool
written by a compiler developer, not a user.
These arguments apply to users but not compiler developers. What do
you think about the latter?
On Mar 7, 2006, at 12:35 PM, Chris Lattner wrote:
> On Tue, 7 Mar 2006, Vikram S. Adve wrote:
>> Changing the heuristics directly would have to be a custom change
>> (i.e., couldn't be checked in). Is there a way for a client pass
>> or tool to influence the heuristics? If not, does it make sense
>> to add such a mechanism?
> To be clear, I'll restate my position here, then follow up with
> more specifics of such a mechanism to Markus' email.
> My basic position is that I think it's a bad thing to let the user
> have fine grained control over optimizations at the source level.
> Being able to say "always force this to be inlined" will make less
> or more sense as the compiler evolves. In particular, as the
> compiler gets better at improving code, the decision about what to
> inline will change, and code that uses thes attributes won't (the
> authors of the code are unlikely to revisit the attributes after
> they are written).
> As one particularly pointed example, the code that uses attributes
> like 'always inline' are typically written and tuned for GCC, often
> for old versions of it. GCC and LLVM (obviously) have very very
> very different optimization capabilities (e.g. LLVM can do
> interprocedural inlining, dead argument elimination,
> interprocedural constant prop, etc), and forcing something to be
> inlined for GCC has a very different impact than does forcing LLVM
> to inline it.
> The meta problem with this is that the code will still *work*, it
> will just perform more poorly than it should. As such, people are
> very unlikely to revisit these attributes after they are initially
> The above is a description of why I think that "always inline" is a
> bad idea to support. However, I *do* [now] support the notion of
> "never inline". In contrast with "always inline", never inline
> sometimes isn't a performance hint: it can be a correctness hint
> and is far more invariant across compiler versions than always
> inline is. While it can obviously be abused, I think the chances
> for its abuse are reduced.
> I will respond to Markus' mail with a concrete proposal for how
> this could be implemented.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev