> I have been working on your patch but I didn't manage to get it
> working yet. Unfortunately our current stable GCC version if 4.3.4 and
> our 4.4.x still has some issues.
> I tried backporting your patch to GCC 4.3.4 but it introduced several
> regressions. It's my guess this is due to my incor
Richard Guenther writes:
>
> Patches should be submitted against SVN trunk head as this is a new
> feature and thus will not go on the 4.4 or 4.5 branches.
Sure. Thanks.
--
PMatos
On Wed, Sep 1, 2010 at 11:11 AM, Paulo J. Matos wrote:
> Richard Guenther writes:
>
>>>
>>> I'd kinda hope that doing the optimization at the tree level means
>>> expand_case
>>> doesn't have to handle both types. The tree code converts sparse case
>>> ranges
>>> to explicit conditionals (or a
Richard Guenther writes:
>>
>> I'd kinda hope that doing the optimization at the tree level means
>> expand_case
>> doesn't have to handle both types. The tree code converts sparse case ranges
>> to explicit conditionals (or a switch on a compact perfect hash), so anything
>> left to RTL expans
On Wed, Sep 1, 2010 at 1:34 AM, Paul Brook wrote:
>> > In fact we might want to move switch optimization up to the tree level
>> > (just because it's way easier to deal with there). Thus, lower switch
>> > to a mixture of binary tree & jump-tables (possibly using perfect
>> > hashing).
>>
>> Doin
> > In fact we might want to move switch optimization up to the tree level
> > (just because it's way easier to deal with there). Thus, lower switch
> > to a mixture of binary tree & jump-tables (possibly using perfect
> > hashing).
>
> Doing the optimisation at the tree-level was exactly my init
> I will be looking at the patch Rahul posted and will try to see if I
> can improve on it.
See attached patch (again) that Paulo is referring to. Sending to GCC
failed due to email client issues.
I have another patch for http://gcc.gnu.org/ml/gcc/2010-08/msg00413.html
Which I will send out short
On Fri, Aug 27, 2010 at 4:03 PM, Richard Guenther
wrote:
>
> In fact we might want to move switch optimization up to the tree level
> (just because it's way easier to deal with there). Thus, lower switch
> to a mixture of binary tree & jump-tables (possibly using perfect
> hashing).
>
Doing the
Another main thing missing is to consider profile information (if
available) so that most frequent cases can be peeled out.
David
On Fri, Aug 27, 2010 at 8:03 AM, Richard Guenther
wrote:
> On Fri, Aug 27, 2010 at 4:47 PM, Ian Lance Taylor wrote:
>> "Paulo J. Matos" writes:
>>
>>> In the first
On Fri, Aug 27, 2010 at 4:47 PM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> In the first case, it generates a binary tree, and in the second two
>> jump tables. The jump tables solution is much more elegant (at least
>> in our situation), generating less code and being faster.
>> Now
On Fri, Aug 27, 2010 at 3:47 PM, Ian Lance Taylor wrote:
>
> I don't know of any specific reason not to look for clusters of switch
> cases. The main issue would be the affect on compilation time. If you
> can do it with an algorithm which is linear in the number of cases, then
> I think it woul
"Paulo J. Matos" writes:
> In the first case, it generates a binary tree, and in the second two
> jump tables. The jump tables solution is much more elegant (at least
> in our situation), generating less code and being faster.
> Now, what I am wondering is the reason why GCC doesn't try to cluste
Hi,
I have been analysing the gcc4.4 code due to the way it's handling:
1 extern void f(const char *);
2 extern void g(int);
3
4 #define C(n) case n: f(#n); break
5
6 void g(int n)
7 {
8 switch(n)
9 {
10 C(0); C(1); C(2); C(3); C(4); C(5); C(6); C(7); C(8); C(9);
11
13 matches
Mail list logo
