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: [PR64164] drop copyrename, integrate into expand


On Thu, Oct 8, 2015 at 12:36 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Sep 29, 2015, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
>> this commit
>
>> commit 33cc9081157a8c90460e4c0bdda2ac461a3822cc
>> Author: aoliva <aoliva@138bc75d-0d04-0410-961f-82ee72b054a4>
>> Date:   2015-09-27 09:02:00 +0000
>
>>     revert to assign_parms assignments using default defs
>>     ...
>
>> introduced a test failure on arm-none-eabi (using newlib, compiling
>> with -mthumb -march=armv8-a -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard ):
>
>> FAIL: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
>
> Thanks for the report.
>
> The problem here is that we don't allocate the pseudo assigned to
> <retval> to r0.  That's because we coalesce <retval> versions with
> another variable that crosses a function call.  We do that because
> uncprop brings these unrelated variables, that happen to contain the
> same -1 value we want to return, into the PHI node with the final
> <retval> value.
>
> We can't coalesce both start and end with <retval>, because start and
> end conflict, but by chance we try start first, and that succeeds.  If
> we tried end first (e.g., by giving it a higher coalesce priority,
> because fewer calls are crossed by its value in the path to the relevant
> edge), we could have got the coalesced variable assigned to r0, and that
> would enable us to optimize out the copy to r0 before return, and so
> merge the return-only basic block with other blocks.  But ATM we don't
> take the definition point or path to the edge into account when
> computing coalesce costs, so we can't deterministically do better for
> this testcase, and I'm not sure using these additional information would
> make it better overall.
>
> Compiling with -fno-tree-dominator-opts skips uncprop so that we don't
> even try to coalesce other variables with <retval>, so we get the code
> expected by the testcase.  But we obviously don't want to disable this
> optimization in general.
>
> Any other thoughts, anyone?

Bad luck?  Add some heuristics that always help?

Ok, that wasn't really useful :/

Richard.

>
> --
> Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


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