jmorse wrote: dblaikie wrote: > I hope that isn't the intent, I thought the intent was just [...]
Ah, by which I mean "it's not an accident", > By just specifying -g Even without -fdebug-info-for-profiling it is going to > introduce debug variables as a sequence of alloca-store-load too, so is it a > requirement to guarantee -O0 output stays identical with or without debug > info? It's a strong objective of LLVM in general to ensure debug-info doesn't have an effect on codegen decisions -- it just makes everything unreliable and hard to predict. It can cause situations where an end user finds their programs behave differently with -g. Having a cc1 option to enable this kind of behaviour is fine as they're relatively experimental, for us the issue is that it's affecting an existing driver option. > Emitting a dbg.value was what I originally though of, but there is a IR > validation pass after frontend codegen that does not permit it, not sure if > there's other design reason for this check Interesting -- I'll admit I'm not especially familiar with stuff right at the front end, but I'm sure I've seen some emails go past about handling dbg.values earlier than normal. @SLTozer @OCHyams were there some Swift related patches that got SROA handling dbg.values correctly, and if so, maybe it's alright for clang to do it too? (@jmorse is still catching up with email). https://github.com/llvm/llvm-project/pull/94100 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
