On Tue, Jan 8, 2013 at 5:16 PM, Jeff Law l...@redhat.com wrote:
On 01/08/2013 04:26 AM, Richard Biener wrote:
The issue is VRP - when you remove unreachable blocks you lose the
conditional statement as it is no longer necessary and thus the predicate
you can derive value-ranges from.
On 01/07/2013 01:42 PM, Steven Bosscher wrote:
typedef enum fruits { banana = 0, apple = 1, pear = 2, orange = 3 } fruit;
extern void price_fruit_of_the_day (int);
void
discount_of_the_day (fruit f)
{
int p, c = (int) f;
switch (f)
{
case banana:
UNREACHABLE ();
case
On 01/07/2013 01:42 PM, Steven Bosscher wrote:
For optimizations it's a bit more difficult.
Somewhat. For what I'm suggesting, the way we'd miss an optimization
would be if by removing the unreachable block and simplifying the CFG we
ultimately remove a conditional which produced a result
On Mon, Jan 7, 2013 at 8:45 PM, Jeff Law l...@redhat.com wrote:
On 01/05/2013 01:10 PM, Steven Bosscher wrote:
Presumably BB7 was created in response to the builtin_unreachable?
Yes. The block only contains the BB_UNREACHABLE call. It is cleaned up
at the end of the GIMPLE passes pipeline,
On Sat, Jan 5, 2013 at 9:10 PM, Steven Bosscher stevenb@gmail.com wrote:
On Thu, Jan 3, 2013 at 9:51 PM, Jeff Law wrote:
On 01/03/2013 12:01 PM, Steven Bosscher wrote:
Hello,
Consider the following test case:
void bar (void);
int foo (int b, int c, int d)
{
int r = 0;
if (b)
On 01/08/2013 04:26 AM, Richard Biener wrote:
The issue is VRP - when you remove unreachable blocks you lose the
conditional statement as it is no longer necessary and thus the predicate
you can derive value-ranges from.
Understood. Perhaps we could eliminate them after the first VRP pass,
On Tue, Jan 8, 2013 at 12:32 PM, Richard Biener wrote:
Does it handle side-effects on the builtin-unreachable path correctly?
int b;
int a;
extern void foo ();
int main()
{
if (!a)
{
if (!b)
foo ();
__builtin_unreachable ();
}
}
---
void foo () {
On 01/05/2013 01:10 PM, Steven Bosscher wrote:
Presumably BB7 was created in response to the builtin_unreachable?
Yes. The block only contains the BB_UNREACHABLE call. It is cleaned up
at the end of the GIMPLE passes pipeline, in the fold-all-builtins
pass (most __builtin_unreachable calls
On Mon, Jan 7, 2013 at 8:45 PM, Jeff Law l...@redhat.com wrote:
Before diving into the patch I think we should figure out why we see such
different effects of eliminating these paths from the CFG. Your assertion
is eliminating them will result in more false positives and less
optimization
On Thu, Jan 3, 2013 at 9:51 PM, Jeff Law wrote:
On 01/03/2013 12:01 PM, Steven Bosscher wrote:
Hello,
Consider the following test case:
void bar (void);
int foo (int b, int c, int d)
{
int r = 0;
if (b)
res = b * 2 + 4;
if (c)
{
if (d)
r = res;
On Sat, Jan 5, 2013 at 9:10 PM, Steven Bosscher wrote:
Bootstrappedtested on powerpc64-unknown-linux-gnu.
And to be clear, bootstrapped with this patch on top:
Index: system.h
===
--- system.h(revision 194924)
+++ system.h
11 matches
Mail list logo
