From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24987 invoked by alias); 19 Apr 2013 09:53:49 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 24942 invoked by uid 48); 19 Apr 2013 09:53:44 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/56944] Better isfinite in some cases? Date: Fri, 19 Apr 2013 09:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Attachment #29900 is obsolete Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg01741.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944 Marc Glisse changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #29900|0 |1 is obsolete| | --- Comment #4 from Marc Glisse 2013-04-19 09:53:42 UTC --- Created attachment 29903 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29903 (x & inf) < inf Slightly improved version of the patch, but there are still issues. Attaching a log of an IRC discussion, so I don't forget all the nice advice: marcg Hello. I added an optab for __builtin_finite and an expander for x86, and it seems to work. To avoid hurting the vectorizer, I also did a vector version, and a builtin and told ix86_builtin_vectorized_function about it, and it works for float. marcg For double, finite takes a double and returns an int, so the vectorizer tries to find a vector version that takes a V2DF and returns a V4SI, whereas I added a version that returns V2DI. richi make sure to also add constant folding marcg (good point about constant folding, thanks) marcg How is the vectorization supposed to work in that case? Should the vectorizer try V2DI as well? richi it's not that easy. I think the target should provide a V2SI variant instead. But of course the vectorizer will ask for V4SI here, so it won't work either. richi the vectorizer simply cannot handle this at the moment (multiple types and calls, in vectorizer speak) richi it would need to go through vectorizable_conversion-like code marcg A V2SI variant would be ugly, mixing vector sizes hurts. richi special-casing the FP classification builtins marcg Ok, I guess I should avoid adding this special 'finite' implementation then richi you can hande it in vectorizer pattern matching, vectorizing it as it was before marcg Ah, indeed, I could have a look (though it is only papering over something, and it is becoming complicated for such a small optimization). Thanks for the explanations. richi yes, it would be a hack jakub marcg: perhaps pattern recognition for that? marcg I think pattern recognition in the vectorizer is the hack richi was talking about? Or do you mean something else? jakub marcg: if you find the target has V{2,4}DF -> V{2,4}DI finite builtin, and code uses DF->SI, then rewrite the __builtin_finite call as __builtin_finitedfdi casted to (int), and the vectorizer will handle the cast richi of course you then need such a builtin richi alternatively you can teach this to call vectorization richi that is, look for a vectorized call that preserves the number of vector elements richi and do the appropriate widening/shortening