[Development] QTBUG-30440: restricting the SIMD files

[Thiago Macieira]

On quinta-feira, 15 de agosto de 2013 12:57:04, Knoll Lars wrote:
> >What's more, on x86, the default 32-bit build is just nonsense today.
> >CPUs 
> >from the past 10 years from both Intel and AMD have had support for SSE2.
> 
> THat's a somewhat separate problem, but I agree that it's time to fix our
> default build flags for Qt. We can IMO assume at least standard SSE2
> instructions. If someone needs something for an older processor, compile
> yourself.

Uh... no, I don't think we can assume that. I'm afraid of Sune and other 
distro packagers! :-)

I do think our buildsystem is already enough. If CXXFLAGS is set on the 
environment, we'll pick it up. If a distribution wants to raise their build 
flags, they can easily do that. In fact, I imagine they already do, in their 
standard buildsystems.

We may consider doing the same in our own binaries. That's our choice.

> >4) Restrict any CPU-specific code to C or C++ source files with limited
> >#include
> >
> >This is the solution I prefer (suggested by Shane on IRC). We'd keep the
> >special compilers, but we'd drop all the include paths for Qt headers.
> >Those 
> >sources would be restricted to system headers, which include the support
> >for 
> >intrinsics.
> >
> >For C++ sources, we need to ensure no Standard Library headers are
> >included 
> >(same problem as Qt headers). ISO C headers are fine, since C89 doesn't
> >support 
> >inlines, and C99 inlines are just plain weird. Most C headers use "static
> >inline" for inlines, which is fine.
> >
> >For that reason, I think we should stick to C, unless there's a very good
> >reason why not (like GCC's dispatch feature, which is only supported in
> >C++).
> 
> I'd agree that option (4) is the cleanest solution. Have you checked how
> much we'd need to change to implement it?

No, not yet.

I don't think it will be too hard because those routines are still fairly 
limited. I will look into this soon.

It's good I never got to cleaning up and pushing my experiments of 18 months 
ago, which I still have in my tree. That went in the complete opposite 
direction of moving more C++ code into the specially-compiled files.

The idea isn't incompatible (moving more code), but we need to be very careful 
now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130815/41fa6352/attachment.sig>