[PATCH][AVX512] Add class to group common template arguments related to vector type

[Demikhovsky, Elena]

Hi Adam,

FloatVT may be illegal if you generate it from v64i8. But in my opinion, you can leave it as is.
In this cases “float casting” is not required.

So, this patch looks good.
Thank you.

-           Elena

From: Adam Nemet [mailto:anemet at apple.com]
Sent: Wednesday, August 20, 2014 23:32
To: Demikhovsky, Elena
Cc: Khasanov, Robert; llvm-commits
Subject: Re: [PATCH][AVX512] Add class to group common template arguments related to vector type

Hi Elena,

On Aug 18, 2014, at 9:31 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com<mailto:elena.demikhovsky at intel.com>> wrote:


Hi Adam,

Some things that I see:

1) I suggest to rename EltNum to NumOfElts

I went with NumElts.  That seems to be used more commonly in headers likes MachineValueTypes.h.

2)
+  // Corresponding write-mask register class.
+  RegisterClass KRC = !cast<RegisterClass>("VK" # EltNum # "WM");
+
+  // The GPR register class that can hold the write mask.
+  RegisterClass MRC = !cast<RegisterClass>("GR" # EltNum);

VK2 is possible, GR2 is not.

Good catch, thanks.  I modified this to give GR8 for NumElts <= 8.


2) I don't think that default rc is good. Let everybody specify register class explicitly.
+class X86VectorVTInfo<int EltNum, ValueType EltVT, RegisterClass rc = VR512,
+                      string suffix = ""> {

Done.


3) Let's assume that I'm building
def v16f32_info :  X86VectorVTInfo<16, f32, VR512, "ps">
how FloatVT will look like?

It would be v16f32, i.e. the original type.


Do we need IntVT for completeness?

Do you think we’ll need it?  I was going to wait until there is a need for it.


4) I suggest to add broadcast string {1toX} to the info.

Done.

Please review the new version.

Adam






-  Elena


-----Original Message-----
From: Adam Nemet [mailto:anemet at apple.com]
Sent: Monday, August 18, 2014 09:17
To: Demikhovsky, Elena; Khasanov, Robert
Cc: llvm-commits
Subject: [PATCH][AVX512] Add class to group common template arguments related to vector type

Hi,

We discussed the issue of generality vs. readability of the AVX512 classes recently.  I proposed this approach to try to hide and centralize the mappings we commonly perform based on the vector type.  A new class X86VectorVTInfo captures these.

The idea is to pass an instance of this class to classes/multiclasses instead of the corresponding ValueType.  Then the class/multiclass can use its field for things that derive from the type rather than passing all those as separate arguments.

I modified avx512_valign to demonstrate this new approach.  As you can see instead of 7 related template parameters we now have one.  The downside is that we have to refer to fields for the derived values.  I named the argument '_' in order to make this as invisible as possible.  Please let me know if you absolutely hate this.  (Also once we allow local initializations in multiclasses we can recover the original version by assigning the fields to local variables.)

Another possible use-case for this class is to directly map things, e.g.:

 RegisterClass KRC = X86VectorVTInfo<32, i16>.KRC

Please let me know if it looks good.

Adam

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140821/d0add45e/attachment.html>