Using associativity for optimization

John Vickers John@XZA5.com
Tue Dec 2 15:01:00 GMT 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Apologies if I'm talking rubbish, or spamming folk with the obvious]

Such an optimisation would ideally be dependent on some estimate on
the register pressure for the relevant register class[es], and perhaps
on some heuristic estimate of the relative execution frequency.

As a standalone function on many RISC machines, register allocation
for foo() is free.  But if we inline foo() into a larger function,
register pressure and code fetch time become more important, perhaps
depending on whether the code is executed at most once per invocation,
or known to be executed a million times per invocation.

John.

On 02/12/14 10:23, Richard Biener wrote:
> On Tue, Dec 2, 2014 at 12:11 AM, shmeel gutl 
> <shmeelgutl@shmuelhome.mine.nu> wrote:
>> While testing my implementation of passing arguments in
>> registers, I noticed that gcc 4.7 creates instruction
>> dependencies when it doesn't have to. Consider:
>> 
>> int foo(int a1, int a2, int a3, int a4) { return a1|a2|a3|a4; }
>> 
>> gcc, even with -O2 generated code that was equivalent to
>> 
>> temp1 = a1 | a2; temp2 = temp1 | a3; temp3 = temp2 | a4;
>> 
>> return temp3;
>> 
>> This code must be executed serially.
>> 
>> Could I create patterns, or enable optimizations that would cause
>> the compiler to generate
>> 
>> temp1 = a1 | a2; temp2 = a3 | a4; temp3 = temp1 | temp2;
>> 
>> Thereby allowing the scheduler to compute temp1 and temp2 in
>> parallel.
> 
> You can tune it with --param tree-reassoc-width=N, not sure if
> that was implemented for 4.7 already.
> 
> Richard.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUfdQ2AAoJEOFemvuvogvZI7cP+gKv+q2ZHlPADVfdU+jK4CRK
RjLtCsfhj216l7mCFB6Gx5FMNExOYkwK3I9r8Da7TC/o/zDAAHX3aqhWFy64/JGW
o1dCZd8Cr1fwTvqM6jWKjcY1ddkdDsPLA2rHG0GZGn6VQWWdyvfpTFNjG8VK4KBl
GO01bcvcHJ88pwQQd2q/4FrFcTcBgdEZO7IfBgTeTEfZDdWPBe9+fWPXvqHoHZRM
ti74fe/8K39SUopVPrBqkgUPXs4iGwNg0VLoRQhRoYeuiruexzXCDAl0j4MuihAD
A4ssrp+CJV6gf7hPiZCm6T8p0XN3+W1UB9xTrn055dujVK0/uSvYhjrR8c3HMx0M
4jRZG7+5tJqC45hEyHZ+m+cmtjIWGzVPevYv2pzH6lyzd8eFf4q+4VBDVdDQRT3s
4RkBosccVgj7CHn0/rVJfTa/ONQMNSikq1HUYeXJwg8Lclm929jXNRP/tEj37OH0
UibM38t+ZMwI0LvKhbQm4904ASFCi8qNTEN/c3VS86A0smMPlGX7OSq2k/IuEcRx
lDd4msu2/aRTIgunmEl2558wlSbOlxtO6jPjri5HdzTajaQSC9t5T3pmi+P+Y5R5
+6OPy/BFSVyqKXS+kPA0IyOFE2iBgbHHfTbtptzeN2Tk3eGm1Ssk20JBqhRBvZTt
/doeToTwibJ8ZDgF2Q/O
=CghE
-----END PGP SIGNATURE-----



More information about the Gcc mailing list