I understand what jump threading does. In theory it reduces number of instructions executed. But it creates messy program structure and prevents further optimizations, at least for target we have (VLIW-based DSP with predicated execution).
I just ran through 8 audio codecs we use as internal benchmark. 5 out of 8 codecs have similar performance with/without jump threading (give or take 0.1-0.2%). For the other 3, no jump threading version outperforms by 1-2.5%. I didn't even enable -ftree-vectorize. I am going to do some further investigation and check whether if-conversion can be fixed without disabling jump threading. Bingfeng -----Original Message----- From: Jeff Law [mailto:l...@redhat.com] Sent: 22 November 2013 17:17 To: Bingfeng Mei; Andrew Pinski; Richard Biener Cc: gcc@gcc.gnu.org Subject: Re: Jump threading in tree dom pass prevents if-conversion & following vectorization On 11/22/13 10:13, Bingfeng Mei wrote: > So if we are about to fix this in if-conversion, we need to do both in tree & > rtl as both ifcvt & ce passes cannot handle it. > > I am still not convinced jump threading is good for target with predicated > execution (assuming no fix for if-conversion). I am doing benchmarking on our > target now. I'd be quite surprised if your tests show that it's not beneficial. In simplest terms jump threading identifies conditional branches which can have their destination statically determined based on the path taken to the static branch. And more generally, we try *real* hard not to start enabling/disabling tree passes on a per-target basis. The end result if we were to start doing that is an unmaintainable mess. Jeff
