This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Make expansion of balanced binary trees of switches on tree level.


On 08/03/2017 03:02 AM, Jan Hubicka wrote:
>> On 08/02/2017 01:51 PM, Richard Biener wrote:
>>> On Wed, Aug 2, 2017 at 1:20 PM, Martin Liška <mliska@suse.cz> wrote:
>>>> Hello.
>>>>
>>>> After some discussions with Honza, I've decided to convert current code in stmt.c that
>>>> is responsible for switch expansion. More precisely, I would like to convert the code
>>>> to expand gswitch statements on tree level. Currently the newly created pass is executed
>>>> at the end of tree optimizations.
>>>>
>>>> My plan for future is to inspire in [1] and come up with some more sophisticated switch
>>>> expansions. For that I've been working on a paper where I'll summarize statistics based
>>>> on what I've collected in openSUSE distribution with specially instrumented GCC. If I'll be
>>>> happy I can also fit in to schedule of this year's Cauldron with a talk.
>>>>
>>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>>>
>>>> Thoughts?
>>>
>>> First of all thanks.
>>>
>>> I think part of switch expansion moved to switch-conversion some time ago
>>> (emit_case_bit_tests).  So maybe the full lowering should be in at least
>>> the same source file and it should maybe applied earlier for a subset of
>>> cases (very low number of cases for example).
>>
>> Yep, good idea. I'll take a look.
>>
>>>
>>> Did you base the code on the RTL expansion code or did you re-write it from
>>> scratch?
>>
>> It's based, I've just changed the function that create CFG.
> 
> I have talked Martin to do this in first step. Switch expansion is infinitely
> difficult problem and I think changing representation first and keeping the
> basic algorithm is easiest way to get something done.  Algorithm will be
> improved next as far as I know :)
I can support that approach :-)


jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]