On Thu, 19 May 2016, Jiong Wang wrote: > Then, > > * if we add scalar HF mode to standard patterns, vector HF modes operation > will be > turned into scalar HF operations instead of scalar SF operations. > > * if we add vector HF mode to standard patterns, vector HF modes operations > will > generate vector HF instructions directly. > > Will this still cause precision inconsistence with old gcc when there are > cascade > vector float operations?
I'm not sure inconsistency with old GCC is what's relevant here. Standard-named RTL patterns have particular semantics. Those semantics do not depend on the target architecture (except where there are target macros / hooks to define such dependence). If you have an instruction that matches those target-independent semantics, it should be available for the standard-named pattern. I believe that is the case here, for both the scalar and the vector instructions - they have the standard semantics, so should be available for the standard patterns. It is the responsibility of the target-independent parts of the compiler to ensure that the RTL generated matches the source code semantics, so that providing a standard pattern for an instruction that matches the pattern's semantics does not cause any problems regarding source code semantics. That said: if the expander in old GCC is converting a vector HF operation into scalar SF operations, I'd expect it also to include a conversion from SFmode back to HFmode after those operations, since it will be producing a vector HF result. And that would apply for each individual operation expanded. So I would not expect inconsistency to arise from making direct HFmode operations available (given that the semantics of scalar + - * / are the same whether you do them directly on HFmode or promote to SFmode, do the operation there and then convert the result back to HFmode before doing any further operations on it). -- Joseph S. Myers jos...@codesourcery.com
