On 05/06/13 21:27, Matthew Gretton-Dann wrote:
Kugan,
I don't have the source code to hand but how are the
sin()/cos()->sincos() optimizations handled?
Thanks Matt. There is a tree level pass to combine sin()/cos() into
sincos(). Commit that added this is:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=121052. We can try
doing same thing similar here.
Is there anyway we can know in the tree level that the target does not
define integer divide?
Thanks,
Kugan
Thanks,
Matt
On 5 June 2013 11:44, Kugan <kugan.vivekanandara...@linaro.org> wrote:
Hi,
I am looking at best approach for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721 - Failure to optimise
(a/b) and (a%b) into single __aeabi_idivmod call in ARM architecture
In sumary, the following c code results in __aeabi_idivmod() call and one
__aeabi_idiv() call even though the former already calculates the quotient.
int q = a / b;
int r = a % b;
return q + r;
My question is what would be the best way to handle it. As I see there are
few options with some issues.
1. Handling in gimple level, try to reduce the operations to equivalent of
this. We should do this for the targets without integer divide.
{q, r} = a % b;
Gimple assign stmts have only one lhs operation (?). Therefore, lhs has to
be made 64bit to signify return values of R0 and R1 returned together. I am
not too sure of any implications on other architectures here.
2. Handling in expand_divmod. Here, when we see a div or mod operation, we
will have to do a linear search to see if there is a valid equivalent
operation to combine. If we find one, we can generate __aeabi_idivmod() and
cache the result for the equivalent operation. As I see, this can get messy
and might not be acceptable.
3. An RTL pass to process and combine these library calls. Possibly using
cse. I am still looking at this.
4. Ramana tried a prototype to do the same using target pattens. He has
ruled this out. (if you want more info, please refer to at
https://code.launchpad.net/~ramana/gcc-linaro/divmodsi4-experiments)
Any suggestion for best way to handle this?
Thanks,
Kugan
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
