This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
- From: "roger at eyesopen dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Jul 2006 19:47:27 -0000
- Subject: [Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
- References: <bug-28283-6755@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #5 from roger at eyesopen dot com 2006-07-06 19:47 -------
No the rtx_costs for a DImode shift really are wrong. The use of the constant
10000 in sh.c:shift_costs instructs the middle-end to avoid using DImode
shifts at all costs. The semantics of rtx_costs is that it is expected to
provide an estimate of the cost of performing an instruction (either in
size when optimize_size or in performance whrn !optimize_size) even if the
hardware doesn't support that operation directly. For example, a backend
may even need to provide estimates of the time taken for a libcall to libgcc,
if such an operation is necessary, or when optimizing for size, how large such
setting up and executing such a call sequence should be.
It's only by providing accurate information such as this that an embedded
backend such as SH is able to provide fine control over the code sequences
selected by the GCC middle-end.
As for the little-endian vs. big-endian issue that looks like a second bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283