nikic wrote: My ideal world here would probably be:
1. Determine IsLarge heuristic based on allocation size only, rather than allocation size of contained arrays. 2. Make strong heuristic purely use-based. Using type based heuristics when we already have use-based ones doesn't really make any sense. This means that for strong protection, no IR annotations are needed. 3. For the basic heuristic, add opt-out metadata in the frontend (in fact, the metadata for this already exists for explicit frontend out-opts). If the metadata is lost, we'll protect a bit too much for the basic heuristic, which I'm not overly concerned about, esp. as anyone doing large scale stack protector deployment is using `-fstack-protector-strong`. Now, if point 1 is not an option and it is actually important that the IsLarge heuristic is only driven by arrays in the allocation, as opposed to total allocation size, then things get a bit uglier. That means we need to annotate IR even in strong mode, and the annotation needs to include IsLarge vs not. If the metadata is dropped, we'd fall back to an allocation-size based IsLarge heuristic. I think this should be fine? I'm not all *that* concerned about metadata preservation here, as we have very few passes that make substantial changes to allocas (mainly SROA, MemCpyOpt and I guess Coro?) And the fallback is still very reasonable. > But also note that accidentally dropping this metadata inherently implies > activating SSP, which will cost program performance. It also means that each > of the ~400 places that construct AllocaInst would need to be "fixed" as > otherwise they would cause a performance impact. Let me turn this argument around: The intrinsic based approach means that all these allocas will silently not get stack protectors. Are you confident that none of them may need them? I'm reasonably sure that people who enable stack protectors would rather have things fail in the direction of "some unnecessary stack protectors added" than "a necessary stack protector not added". Esp. if this is still falling back to the strong use-based heuristic, which will prevent protectors where they are trivially unnecessary. https://github.com/llvm/llvm-project/pull/183623 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
