Re: Passsing unfinished types to gen_type_die_with_usage

[Jason Merrill]

On 05/14/2015 10:29 AM, Jan Hubicka wrote:

Is it expected & safe for dwarf2out to process unfinished types?


Yes, they are treated as an incomplete forward declaration.


It seems to me that we may wan to delay rest_of_type_compilation for time the 
contexts are
finished, to..


I wouldn't complain about that, but it doesn't seem necessary.

I don't think you want to check TYPE_BINFO if !COMPLETE_TYPE_P.

Jason

if-else-if chains to switch conversion optimization

[Daniel Gutson]

Hi,

  the particular motivation is a TMP compile-time search of an
element, but could be extended to other scenarios.

In my example, given:

template 
struct Static_Find
{
static size_t find(size_t /*target*/)
{
return 0;
}
};

template 
struct Static_Find
{
static size_t find(size_t target)
{
return target == Head ? Count : Static_Find::find(target);
}
};

template
size_t static_find(size_t target)
{
return Static_Find<0u, List...>::find(target);
}

consider these functions:

size_t func1(size_t x)
{
return static_find<1, 4, 5, 10, 100>(x);
}

size_t func2(size_t x)
{
switch(x)
{
case 1: return 0;
case 4: return 1;
case 5: return 2;
case 10: return 3;
case 100: return 4;
}
return 0;
}

Using gcc 5 and below, the generated code of func2 outperforms func1
since switch-cases can be
alternatively emitted as a binary tree or a branch table. I have not
seen any equivalent optimizations
for an if-else-if chain (as is func1 generated), or at least a
conversion from the chain to the switch (whereas the opposite does
exist IIUC tree-switch-conversion).

Does such converting optimization (if-else-if chain to switch) exist
and I didn't see it? If it doesn't,
is there any reason or just nobody coded it yet?

Thanks,

   Daniel.


-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson