Re: [Patch,AVR]: Fix PR50910: int/2 leads to libgcc call

2011-11-01 Thread Denis Chertykov
2011/10/31 Georg-Johann Lay a...@gjlay.de: This is a fix for optimization flaw when dividing int by 2. There is really no need for a library call. Costs of [U]DIV/[U]MOD are adjusted to take into account the costs of CONST_INT operands that must be loaded for division by means of libgcc

Re: [Patch,AVR]: Fix PR50910: int/2 leads to libgcc call

2011-11-01 Thread Georg-Johann Lay
Denis Chertykov schrieb: 2011/10/31 Georg-Johann Lay: Since beginning of time, BRANCH_COST was set to 0 so that some optimization passes make code happily jumping around. The patch introduces a new command line option for that; mainly because I don't know the rationale behind setting

Re: [Patch,AVR]: Fix PR50910: int/2 leads to libgcc call

2011-11-01 Thread Denis Chertykov
2011/11/1 Georg-Johann Lay a...@gjlay.de: Denis Chertykov schrieb: 2011/10/31 Georg-Johann Lay: Since beginning of time, BRANCH_COST was set to 0 so that some optimization passes make code happily jumping around. The patch introduces a new command line option for that; mainly because I

[Patch,AVR]: Fix PR50910: int/2 leads to libgcc call

2011-10-31 Thread Georg-Johann Lay
This is a fix for optimization flaw when dividing int by 2. There is really no need for a library call. Costs of [U]DIV/[U]MOD are adjusted to take into account the costs of CONST_INT operands that must be loaded for division by means of libgcc call. There are some new combiner patterns suffixed