This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Saturating using arithmetic in address calculation.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, <libc-alpha at sourceware dot org>
- Date: Sat, 26 Oct 2013 21:26:28 +0000
- Subject: Re: [RFC] Saturating using arithmetic in address calculation.
- Authentication-results: sourceware.org; auth=none
- References: <20131025084008 dot GA17443 at domone> <526A319B dot 80909 at suse dot com> <Pine dot LNX dot 4 dot 64 dot 1310251530510 dot 12877 at digraph dot polyomino dot org dot uk> <526A92D7 dot 6040501 at cs dot ucla dot edu> <20131026150755 dot GA20393 at domone dot podge>
On Sat, 26 Oct 2013, Ondrej Bilka wrote:
> For that performance a assembly version/gcc builtin would be needed. A
> portable implementation would have comparable performance with manual
> checks.
For saturating multiplication in size_t where one argument is a constant,
I don't think much optimization arises. There may be other cases where
such optimizations would be more significant.
I don't think C does a good job of providing fine control of overflow
handling of integer operations, such as saturating arithmetic, although
there are various purposes for which you'd like to do such an operation
explicitly and let the compiler work out how best to optimize it for a
given system, rather than writing more complicated C code and hoping that
the compiler can recognize your idiom (see
<http://saluc.engr.uconn.edu/refs/compiler/bik02idioms.pdf> for how some
idioms might be recognized). In particular, I think the TR 18037
(embedded C) approach of saturating fixed-point types with a keyword _Sat
is poorly matched to the uses of saturation in typical C code (it may be
of more use to the target DSP audience of that TR) - and that the
implementation approach for that TR in GCC, using a large number of new
machine modes rather than lowering to operations on generic types and
modes, is also problematic.
However, that TR 18037 approach is what there's so far been interest in
standardizing, or in implementing in GCC, rather than any approach for
operations with explicit overflow handling such as discussed in GCC PR
48580.
--
Joseph S. Myers
joseph@codesourcery.com