[PATCH] D46300: [Clang] Implement function attribute no_stack_protector.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.


================
Comment at: include/clang/Basic/Attr.td:1494
+def NoStackProtector : InheritableAttr {
+  let Spellings = [GCC<"no_stack_protector">];
+  let Subjects = SubjectList<[Function]>;
----------------
aaron.ballman wrote:
> manojgupta wrote:
> > aaron.ballman wrote:
> > > This is not a GCC attribute, so this should use the Clang spelling.
> > > 
> > > However, why spell the attribute this way rather than use the GCC spelling (`optimize("no-stack-protector")`?
> > Thanks, I have changed it to use Clang spelling.
> > 
> > Regarding __attribute__((optimize("..."))), it is a generic facility in GCC that works for many optimizer flags.
> > Clang currently does not support this syntax currently instead preferring its own version for some options e.g. -O0. 
> > e.g.  
> > ```
> > __attribute__((optimize("O0")))  // clang version is __attribute__((optnone)) 
> > ```
> > If we want to support the GCC syntax, future expectation would be support more flags under this syntax. Is that the path we want to take (I do not know the history related to previous syntax decisions but better GCC compatibility will be a nice thing to have) 
> The history of `optnone` predates my involvement with Clang and I've not been able to find the original review thread (I did find the one where I gave my LGTM on the original patch, but that was a resubmission after the original design was signed off).
> 
> I'm not keen on attributes that have the same semantics but differ in spelling from attributes supported by GCC unless there's a good reason to deviate. Given that we've already deviated, I'd like to understand why better -- I don't want to push you to implement something we've already decided was a poor design, but I also don't want to accept code if we can instead use syntax that is compatible with GCC.
I do not think we want to pursue supporting generic optimization flags with `__attribute__((optimize("...")))`.

Part of the reason we only support `optnone` is that LLVM's pass pipeline is global to the entire module. It's not trivial to enable optimizations for a single function, but it is much easier to have optimization passes skip functions marked `optnone`.


Repository:
  rC Clang

https://reviews.llvm.org/D46300