search for: dallman

On 7 June 2013 13:53, Dallman, John <john.dallman at siemens.com> wrote: > It needs to be possible to debug code at any optimisation level. > Yes, I agree. But after O1, sequential execution is a big impediment for optimizations, and keeping the debug information valid after so many transformations might pose a b...

...s come from which source statements, and which variables are being accessed. The absence of debug information at that level tends to require going through an entire function figuring out what every instruction does, and how it relates to the source, which is rather time-consuming. thanks, -- John Dallman From: Renato Golin [mailto:renato.golin at linaro.org] Sent: 07 June 2013 17:39 To: Dallman, John Cc: LLVM Dev; Clang Dev Subject: Re: [cfe-dev] Meaning of LLVM optimization levels On 7 June 2013 13:53, Dallman, John <john.dallman at siemens.com<mailto:john.dallman at siemens.com>> wr...

...t optimistic -- this approach won't get you anything any time soon. Dean Sutherland dsutherland at cert.org<mailto:dsutherland at cert.org> On Jun 7, 2013, at 12:38 PM, Renato Golin <renato.golin at linaro.org<mailto:renato.golin at linaro.org>> wrote: On 7 June 2013 13:53, Dallman, John <john.dallman at siemens.com<mailto:john.dallman at siemens.com>> wrote: It needs to be possible to debug code at any optimisation level. Yes, I agree. But after O1, sequential execution is a big impediment for optimizations, and keeping the debug information valid after so many...

...o optimisation levels, it's quite helpful to have a way of controlling optimisation on a function-by-function level. This is very useful when you're trying to work out where in a file with many functions an optimiser problem is happening; it isn't foolproof, but it helps a lot. -- John Dallman From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Renato Golin Sent: 06 June 2013 21:41 To: LLVM Dev; Clang Dev Subject: [cfe-dev] Meaning of LLVM optimization levels Folks, I'm trying to rationalize about optimization levels and maybe we should come u...

...ion 2) Improve debuggability of optimized code. GCC has -Og option that can be used to generate well optimized code with good debuggability. 3) there is a much bigger issue if the customer needs to resort to this pragmas frequently to hide optimizer bugs. David On Wed, Jun 12, 2013 at 8:11 AM, Dallman, John <john.dallman at siemens.com> wrote: >> Although both cases would be nice and our users have expressed some >> interest in both, the critical one is the second case of making sure that >> some functions are never optimized is the most critical one. The major >>...

...rt to > this pragmas frequently to hide optimizer bugs. I agree, these are indeed questionable. However, there is a very important use case that I would call "performance tuning of critical code segments". Cheers, Ralf > > David > > > On Wed, Jun 12, 2013 at 8:11 AM, Dallman, John <john.dallman at siemens.com> wrote: >>> Although both cases would be nice and our users have expressed some >>> interest in both, the critical one is the second case of making sure that >>> some functions are never optimized is the most critical one. The maj...

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com> wrote: > Is it possible for the debug information to mark all the instructions > that arise from a > > language statement as coming from that statement, even though the > instructions may > > be widely scattered? > I'm not awa...

...ugs, possibly because it is very thoroughly tested. Optimization control pragmas are invaluable for locating optimizer bugs in a particular function; the lack of them is one of the reasons why my GCC and Clang builds don't have optimization turned up so high as on some other compilers. -- John Dallman ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

In reply to the question about what would be the common use case: > What is the common use case? Making sure some funtion is always > optimized or making sure it never optimized? If the second one, I > wonder if marking it cold would be a good enough approximation. Although both cases would be nice and our users have expressed some interest in both, the critical one is the second case

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com> wrote: > Is it possible for the debug information to mark all the instructions that arise > from a > language statement as coming from that statement, even though the instructions may > be widely scattered? Yes. > Instructions whose effects...

Folks, I'm trying to rationalize about optimization levels and maybe we should come up with a document like this: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html Though, I remember a discussion a few months ago, and some people recommended we had names, rather than numbers, to dissociate the idea that 3 is better than 2. Regardless, would be good to have some guidelines on what goes