This was implemented in karmic gcc-4.4 4.4.1-3ubuntu2
** Package changed: gcc-4.3 (Ubuntu) = gcc-4.4 (Ubuntu)
** Changed in: gcc-4.4 (Ubuntu)
Status: In Progress = Fix Released
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification
** Tags added: armel
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
So for karmic we're aiming at:
-march=armv6 -mtune=cortex-a8 -mfpu=vfp -mfloat-abi=softfp
** Changed in: gcc-4.3 (Ubuntu)
Status: Confirmed = In Progress
** Changed in: gcc-4.3 (Ubuntu)
Assignee: (unassigned) = Matthias Klose (doko)
--
armel gcc default optimisations
Let's discuss opts for karmic here;
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-vfp list the bugs
for the VFP optimized libs.
** Changed in: gcc-4.3 (Ubuntu Jaunty)
Status: Confirmed = Won't Fix
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You
So I counted the number of float and double words in the source code of the
various libraries proposed here with:
egrep -hrwc double\|float . | xargs | sed 's/ / + /g' | bc
that gave:
- pixman: 66 = likely no vfp version
- cairo: 2423 = will have a vfp version
- pango1.0: 683 = will have a vfp
Dave, first, thanks for your list of libs; I'd like to refine the list here.
I think Matthias looked at building multiple libgcc but that didn't see to
work too well; it might not be interesting either as libgcc is meant to be a
software implementation and hence doesn't have code to use use a
Dave, on the use of multiple sources.list entries:
Note that http://mojo.handhelds.org/hasty-armv6el-vfp/ only cascades deb-src
entries. We discussed the idea of another archive, but this is quite a stretch
to setup and maintain; of course you need infrastructure (disk space, buildds,
Emmet, I don't think runtime detection is a good idea for FPU; you would
end up reimplementing the hwcap mechanism to select between two flavours
of the library IMO -- unless all floating point is already in a dlopen-
ed plugin, but that's not really the case for the libs here.
Also, I think we
I've been taking a look at package lists and the dependencies of key
apps and libraries. The following look worth investigating with respect
to VFP optimisations:
I haven't tidied this list up fully, so there is a mix of binary and
source package names... I've done no benchmarking or profiling
Argh, tabs get entered in the thread as nbsp; --- if anyone finds that
last post hard to read, let me know and I'll repost it in a more
readable way.
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification because you are a member of Ubuntu
I was also having a chat with Catalin about an alternative way of making
VFP optimisations available.
I observed that Handhelds Mojo addresses architecture variants by having
special package servers which are placed at the start of the apt sources
list. See
Given the nature of the Ubuntu archives, it's probably easier to have
differently named packages (e.g. libpangomm-1.4-1-vfp) distributed in
the same archive, and maybe have a metapackage that pulled all the -vfp
variants to ease the user experience than to try to configure multiple
parallel
Catalin, thanks for your proposal; we discussed this option this week
since we were meeting with other Canonical people, notably Matthias and
Colin.
On the idea to handle all VFP instructions as kernel traps on systems
without a FPU, we think it will be too slow. In my experience, even
alignment
Thinking a bit more, I think the VFP emulation for older hardware could
be a viable option to have all the packages compiled with -mfpu=vfp. I
can't estimate the performance difference between softfloat and VFP
emulation but, if the performance on Xscale is visibly affected, we
still have the
On Thu, 2009-01-22 at 15:58 +, Loïc Minier wrote:
[Ack, I do understand there's a performance hit when gong via libgcc,
but I was hoping this could be a good compromise between not using
hardware FPU at all and generating traps on systems without FPU.]
I haven't looked but I think there is
On Wed, Jan 28, 2009 at 11:17:27AM -, Catalin Marinas wrote:
On Thu, 2009-01-22 at 15:58 +, Loïc Minier wrote:
Concerning libm as a candidate for opts: libm is in libc which is
definitely a candidate for an optimized version; for example with have
an i686 version for the i386 arch
Catalin Marinas schrieb:
I didn't find any flags in the gcc man page about VFPv2 or v3: I guess
one can only tell gcc to generate instructions for the full VFP set or
not at all.
By default, with -mfpu=vfp, the compiler generates VFPv2 code and I
think that's what should be used as VFPv3
compared pybench and pystone benchmark results. Compared to a default to
armv5 with the proposed flags, together with a glibc built with the
proposed flags, you do see 4-5% improvement in the benchmarks. Note that
these benchmarks don't use floating point.
--
armel gcc default optimisations
Which board was this on?
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Dave Martin schrieb:
Which board was this on?
my python benchmarks were done on the babbage board.
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
This seems like a plausible amount of improvement for Cortex-A8 tuning
on a non-floating-point-intensive package and library stack.
Did you get a chance to try interoperable non-vfp code on ARM9/XScale?
(i.e., -march=armv5 -mtune=cortex-a8... I'm assuming -msoft-float is present
by default).
Interesting results, but I guess we would not expect to see much of a
performance increase by building python with hardware floating-point.
It's an interpreter, so I expect that floating-point instructions are
going to account for only a small proportion of the code executed, even
when the python
I did some performance benchmarks with pybench on an ARMv7 board. To
prevent any third party processes from interfering, the board was
running Ubuntu in single user mode, and the stock glibc. I'll run
another set of benchmarks with our glibc tuned with the proposed flags,
and also do another set
By default, gcc generates software floating point, so for this
particular case no additional command line options are needed.
Using -mfloat-abi=softfp indeed creates binaries compatible with Debian
(soft-float) since the function calling convention uses standard
registers and stack for passing
Right, so -mfloat-abi=softfp generates binaries which use compatible
calling conventions but do require a VFP.
I don't think we want this; instead we should rather optimize libs and
programs to select VFP at runtime if available or provide alternate
packages for VFP versus non VFP systems. One
(Typo s/VFP/FPU on the first line above, sorry.)
Does someone have pointers on the VFP trap handling kernel patches and
on the issues with them (I guess there are issues if the patches aren't
in the mainline)?
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You
If -mfpu=vfp is enabled, the compiler will generate VFP instructions in
the asm code directly rather than calls to the libgcc soft-float code.
Even if the libgcc soft-float function could be replaced with the VFP
instructions, you still get an additional branch to those operations and
probably
Please ignore the legal disclaimer at the end of the previous post (I
used the wrong SMTP server and it got appended automatically). Thanks.
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification because you are a member of Ubuntu
Bugs, which
[Ack, I do understand there's a performance hit when gong via libgcc,
but I was hoping this could be a good compromise between not using
hardware FPU at all and generating traps on systems without FPU.]
Concerning libm as a candidate for opts: libm is in libc which is
definitely a candidate for
** Changed in: gcc-4.3 (Ubuntu)
Importance: Undecided = High
Status: New = Triaged
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
no, it's not triaged.
- is -mtune=cortex-a8 our choice? how does it affect other processors?
- is -march=armv5t needed? afaiu we cannot run anymore on the thecus (Xscale)
** Changed in: gcc-4.3 (Ubuntu)
Status: Triaged = Incomplete
--
armel gcc default optimisations
The -mtune=cortex-a8 will optimise the generated code for the Cortex-A8
(ARMv7 processor) pipeline but not affecting the instruction set used
(which is still ARMv5T). The resulting code will be optimal on ARMv7 but
there may be a slight drop (if any) on other architecture versions.
Without the
Catalin, we'd like to support the Thecus N2100 and other XScale IOP32x
with the -iop32x kernel flavour. The N2100 has a IOP 80219 which is
ARMv5TE and like you I think it lacks a FPU.
Debian uses -mfloat-abi=soft; I understand that using -mfloat-abi=softfp
creates binaries which are compatible
33 matches
Mail list logo
