[PATCH] D132623: [CodeGen] Disable tail calls at -O0/-O1

Mon Sep 12 11:34:28 PDT 2022

dblaikie added a subscriber: chandlerc.
dblaikie added a comment.

> In D132623#3779146 <https://reviews.llvm.org/D132623#3779146>, @dblaikie wrote:
>
>>> For that reason I don't think the frontend should be responsible for adding the attribute.
>>
>> Not sure I follow - the "optnone at -O0" is implemented in the frontend, seems suitable to implement this one the same way, especially if we already have the attribute and infrastructure for it?
>
> This actually came up in a talk with some people recently.
> It would be interesting to have some sort of monolithic pipeline where we embed -O0/1/2/3/s/z attributes per-function in the frontend and don't have per-optimization-level pipelines. Currently we have function attributes for -O0/s/z but not the others. -O1 is fairly distinct from -O2/3 in that we want to preserve debuggability. However, we don't have an -O1 function attribute yet, so I don't think what you're proposing makes sense with the current state of things where we express our intent via the optimization level parameter to the optimization pipeline.

At least when I think optnone (or maybe optsize, I forget - I remember it was @chandlerc that was expressing these opinions most vocally) was proposed there was some distinction drawn between semantically meaningful differences (that "optimizing for size" and "not optimizing at all" were observable changes in behavior, in some sense - for debugging, for fitting in certain embedded devices, etc) and "varying shades of optimization" (essentially between -O2 and -O3) - and that the latter didn't seem suitable for per-function granularity expression (& so should be expressed only by the optimization pipeline, not embedded in the IR), but the former did.

As -O1 becomes/meanders near -Og, I guess we might end up with another of these "but this needs to be carried in the IR/is semantically meaningful to the end user" attributes ("optdebug"?) - but I don't know that we're there yet. I think if -O1/-Og's desire to be debuggable can be expressed by the frontend as much as possible with existing attributes in a similar way to -O0/optnone, that's a good thing - makes it more compatible with LTO, at least?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132623/new/

https://reviews.llvm.org/D132623