dougsonos wrote: > I’m probably just stating the obvious here, but seeing as existing code > obviously does not make use of effects, for compiling it to become slower, > that means that we’re probably unconditionally executing code somewhere > irrespective of whether effects are present or not, so what I’m saying is we > should probably investigate any places where this pr checks for the presence > of effects and does something based on that and move the checks for whether a > function even has effects attached to it as far up as possible and try and > also optimise that check (is the function that checks for that defined in a > header? If not, we should maybe move the definition there so it can be > inlined).
That makes sense. I remember thinking a couple of times that I was working on a function that might be better inlined, but changing Type.h triggered long rebuilds. > The only other option I can think of is that this adds some more data to > `FunctionProtoType`s, which means we allocate more etc. but that alone > shouldn’t have this big of an impact I’m assuming? Well, it adds two more types of trailing objects so nothing more gets allocated in the case of no effects. Possibly the trailing objects mechanism itself gets a bit slower though. I'll dig in and investigate today. https://github.com/llvm/llvm-project/pull/84983 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
