Page MenuHomePhabricator

simoll (Simon Moll)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 23 2017, 12:28 AM (167 w, 1 d)

Recent Activity

Yesterday

simoll committed rGe981a46a772f: [VE] Update lea/load/store instructions (authored by kaz7).
[VE] Update lea/load/store instructions
Mon, Apr 6, 3:13 AM
simoll closed D76822: [VE] Update lea/load/store instructions.
Mon, Apr 6, 3:13 AM · Unknown Object (Project), Restricted Project

Fri, Apr 3

simoll accepted D76822: [VE] Update lea/load/store instructions.

LGTM

Fri, Apr 3, 6:57 AM · Unknown Object (Project), Restricted Project

Mon, Mar 30

simoll added a comment to D76822: [VE] Update lea/load/store instructions.

I did git ci -a --amend and arc diff. I guess it corrupts comments from reviewers. I'll try git ci -a and arc diff next time.

Mon, Mar 30, 12:29 AM · Unknown Object (Project), Restricted Project

Thu, Mar 26

simoll added a comment to D76843: [Openmp] Libomptarget plugin for NEC SX-Aurora.

Thanks for working on this!
Comments are mostly nitpicks. I am not sure we can assume that the VEOS device ids are consecutive.

Thu, Mar 26, 8:38 AM · Restricted Project, Unknown Object (Project)
simoll added a reviewer for D76843: [Openmp] Libomptarget plugin for NEC SX-Aurora: efocht.
Thu, Mar 26, 7:00 AM · Restricted Project, Unknown Object (Project)
simoll added a comment to D76822: [VE] Update lea/load/store instructions.

Thank you for the patch!
I've added a few minor remarks inline. Otherwise, this looks good to go to me.

Thu, Mar 26, 1:35 AM · Unknown Object (Project), Restricted Project

Wed, Mar 25

simoll committed rG28a42dd1b9e9: [VE] Change name of enum to CondCode (authored by kaz7).
[VE] Change name of enum to CondCode
Wed, Mar 25, 1:35 AM
simoll closed D76747: [VE] Change name of enum to CondCode.
Wed, Mar 25, 1:35 AM · Unknown Object (Project), Restricted Project

Thu, Mar 19

simoll added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

FYI, the VP-integer intrinsics & langref patch is in. Next up: expansion to standard SIMD IR. I'll announce the next patch also on llvm-dev when it's on phabricator.

Thu, Mar 19, 3:44 AM · Restricted Project
simoll committed rG733b3199487a: [VP,Integer,#1] Vector-predicated integer intrinsics (authored by simoll).
[VP,Integer,#1] Vector-predicated integer intrinsics
Thu, Mar 19, 3:12 AM
simoll closed D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
Thu, Mar 19, 3:12 AM · Restricted Project

Tue, Mar 17

simoll committed rG6bbbead7be2d: [VE] Move VEInstPrinter.cpp and VEInstPrinter.h into MCTargetDesc (authored by kaz7).
[VE] Move VEInstPrinter.cpp and VEInstPrinter.h into MCTargetDesc
Tue, Mar 17, 3:44 AM
simoll closed D76270: [VE] Move VEInstPrinter.cpp and VEInstPrinter.h into MCTargetDesc.
Tue, Mar 17, 3:44 AM · Unknown Object (Project), Restricted Project
simoll accepted D76270: [VE] Move VEInstPrinter.cpp and VEInstPrinter.h into MCTargetDesc.

Thank you for the patch!

Tue, Mar 17, 1:34 AM · Unknown Object (Project), Restricted Project

Fri, Mar 13

simoll updated the diff for D57504: RFC: Prototype & Roadmap for vector predication in LLVM.
  • Rebased
  • %evl < W or UB ensues
  • fixed LangRef wording
Fri, Mar 13, 8:01 AM · Restricted Project
simoll updated the diff for D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
  • Rebased
  • Fixed off-by-one error in the Langref (the lane at position i with i == %evl is False).
Fri, Mar 13, 4:24 AM · Restricted Project
simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

OK. Since the behavior for out-of-range evl is target-dependent, undefined makes sense.

I don't know if you were waiting for input from anyone else, but this looks good to me.

Great :) Thanks to everybody involved for reviewing!
We've iterated on this patch for a while and the last major update was weeks ago, giving people enough time to react to it. I'll commit this today.

Given the scale of the change, it might be good to let people on llvm-dev know that a this patch is ready to land and it is about to be committed (and wait till early next week in case there's additional feedback).

Fri, Mar 13, 3:41 AM · Restricted Project
simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

OK. Since the behavior for out-of-range evl is target-dependent, undefined makes sense.

I don't know if you were waiting for input from anyone else, but this looks good to me.

Fri, Mar 13, 2:15 AM · Restricted Project

Thu, Mar 12

simoll committed rGc8e1081da628: [VE][nfc] Use RRIm for RRINDm, remove the latter (authored by simoll).
[VE][nfc] Use RRIm for RRINDm, remove the latter
Thu, Mar 12, 8:09 AM
simoll closed D76063: [VE][nfc] Use RRIm for RRINDm, remove the latter.
Thu, Mar 12, 8:08 AM · Restricted Project, Unknown Object (Project)
simoll created D76063: [VE][nfc] Use RRIm for RRINDm, remove the latter.
Thu, Mar 12, 7:03 AM · Restricted Project, Unknown Object (Project)
simoll updated the diff for D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

NFC

  • Rebased
  • getModule()
Thu, Mar 12, 3:46 AM · Restricted Project
simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

I'm satisfied with the functionality, but I'm not sure about the intrinsics having undefined behavior outside the [0, W] range. The way you've implemented it, it seems like the behavior would be predictable. If the evl argument is outside that range, it is ignored.

To directly lower VP to NEC SX-Aurora %evl strictly needs to be within the range 0 to W or you get a hardware exception. Defining any behavior outside of that range thus implies additional instructions to restrict %evl to its bounds or guard the VP op. Clearly we do not want that. At the same time un-defining the behavior outside of that range does not hamper AVX512 code generation in any way.

Thu, Mar 12, 2:19 AM · Restricted Project

Wed, Mar 11

simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

Ping. The i32 -1 special case is gone and canIgnoreVectorLength works for both regular and scalable vector types. Are there any more comments or can this go in?

Wed, Mar 11, 1:35 AM · Restricted Project

Tue, Mar 10

simoll committed rG3dabad1af38c: [VE] Target-specific bit size for sjljehprepare (authored by kaz7).
[VE] Target-specific bit size for sjljehprepare
Tue, Mar 10, 10:20 AM
simoll closed D71337: [VE] Target-specific bit size for sjljehprepare.
Tue, Mar 10, 10:20 AM · Unknown Object (Project), Restricted Project
simoll committed rGd871ef4e6ade: [instcombine] remove fsub to fneg hacks; only emit fneg (authored by simoll).
[instcombine] remove fsub to fneg hacks; only emit fneg
Tue, Mar 10, 9:14 AM
simoll closed D75467: [instcombine] remove fsub to fneg hacks; only emit fneg.
Tue, Mar 10, 9:14 AM · Restricted Project, Restricted Project
simoll updated the diff for D75467: [instcombine] remove fsub to fneg hacks; only emit fneg.
  • NFC
  • Fixed code comments
  • Rebased
Tue, Mar 10, 8:40 AM · Restricted Project, Restricted Project
simoll added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

FYI, the test failures you are seeing here are due to the generalized pattern matching doing a better job at matching the fsub idiom for fneg. The required test changes are included in https://reviews.llvm.org/D75467 .

Tue, Mar 10, 5:48 AM · Restricted Project
simoll added a comment to D71337: [VE] Target-specific bit size for sjljehprepare.

ping. Any more comments for this one?

Tue, Mar 10, 5:48 AM · Unknown Object (Project), Restricted Project
Herald added a reviewer for D75467: [instcombine] remove fsub to fneg hacks; only emit fneg: aartbik.

ping. Is this good to go?
(merge bot failures are due to the m_UnOp syntax, which goes against the coding standard).

Tue, Mar 10, 5:13 AM · Restricted Project, Restricted Project

Mon, Mar 9

simoll updated the diff for D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
  • Rebased
  • removed i32 -1 special case for EVL in VP intrinsics - 0 <= %evl < W is the only valid (== defined) setting now.
Mon, Mar 9, 10:46 AM · Restricted Project

Mar 5 2020

simoll added inline comments to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
Mar 5 2020, 1:08 AM · Restricted Project

Mar 3 2020

simoll updated the diff for D75467: [instcombine] remove fsub to fneg hacks; only emit fneg.

NFC

  • rebased
  • formatting
Mar 3 2020, 4:11 AM · Restricted Project, Restricted Project
simoll added inline comments to D75467: [instcombine] remove fsub to fneg hacks; only emit fneg.
Mar 3 2020, 1:43 AM · Restricted Project, Restricted Project
simoll updated the diff for D75467: [instcombine] remove fsub to fneg hacks; only emit fneg.

Thanks for the review!

Mar 3 2020, 1:43 AM · Restricted Project, Restricted Project

Mar 2 2020

simoll created D75467: [instcombine] remove fsub to fneg hacks; only emit fneg.
Mar 2 2020, 9:29 AM · Restricted Project, Restricted Project
simoll updated the diff for D71337: [VE] Target-specific bit size for sjljehprepare.
  • rebased
  • simplified test
Mar 2 2020, 2:18 AM · Unknown Object (Project), Restricted Project

Feb 27 2020

simoll committed rGddd11273d9d0: Remove BinaryOperator::CreateFNeg (authored by simoll).
Remove BinaryOperator::CreateFNeg
Feb 27 2020, 9:52 AM
simoll closed D75130: Remove BinaryOperator::CreateFNeg.
Feb 27 2020, 9:52 AM · Restricted Project, Restricted Project
simoll updated the diff for D75130: Remove BinaryOperator::CreateFNeg.
  • rebased
Feb 27 2020, 9:05 AM · Restricted Project, Restricted Project

Feb 25 2020

simoll added inline comments to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
Feb 25 2020, 10:07 PM · Restricted Project
simoll added inline comments to D75130: Remove BinaryOperator::CreateFNeg.
Feb 25 2020, 1:52 PM · Restricted Project, Restricted Project
simoll updated the diff for D75130: Remove BinaryOperator::CreateFNeg.
  • rebased
  • fixed clang complex-math test
Feb 25 2020, 12:31 PM · Restricted Project, Restricted Project
simoll added reviewers for D75130: Remove BinaryOperator::CreateFNeg: arsenm, craig.topper, rengolin, cameron.mcinally, spatel, mcberg2017, xbolva00.
Feb 25 2020, 11:33 AM · Restricted Project, Restricted Project
simoll created D75130: Remove BinaryOperator::CreateFNeg.
Feb 25 2020, 11:27 AM · Restricted Project, Restricted Project
simoll updated the diff for D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

nfc: spelling, rebased

Feb 25 2020, 7:06 AM · Restricted Project

Feb 24 2020

simoll updated the diff for D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
  • new LangRef wording
  • updated 'VPIntrinsic::canIgnoreVectorLengthParam` to be in line with the i32 -1 constant being the off switch for evl.
Feb 24 2020, 5:48 PM · Restricted Project
simoll planned changes to D71337: [VE] Target-specific bit size for sjljehprepare.

Thanks for having a look :)

Feb 24 2020, 5:39 PM · Unknown Object (Project), Restricted Project
simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

Thanks for the review!
I'll update shortly with an explicit mention of scalable vector types in the langref.

Feb 24 2020, 5:21 PM · Restricted Project
simoll updated the diff for D57504: RFC: Prototype & Roadmap for vector predication in LLVM.
  • rebased
  • various fixes
  • includes llangref rephrasing and atest changes to VP integer patch
Feb 24 2020, 12:39 PM · Restricted Project
simoll added a comment to D71337: [VE] Target-specific bit size for sjljehprepare.

ping?

Feb 24 2020, 9:53 AM · Unknown Object (Project), Restricted Project
simoll updated the diff for D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
  • added section that %evl is disencouraged for non-evl targets
  • The VP intrinsic has UB if the effective EVL is out of bounds.
  • Use i32 -1 as special value for %evl (disabling %evl for this VP call).
Feb 24 2020, 7:53 AM · Restricted Project

Feb 22 2020

simoll committed rG635034f19387: [VE][fix] missing include (authored by simoll).
[VE][fix] missing include
Feb 22 2020, 2:02 AM

Feb 18 2020

simoll committed rG5526786a56bd: [VE] TLS codegen (authored by kaz7).
[VE] TLS codegen
Feb 18 2020, 7:12 AM
simoll closed D74718: [VE] TLS codegen.
Feb 18 2020, 7:12 AM · Restricted Project, Unknown Object (Project)
simoll updated the diff for D71337: [VE] Target-specific bit size for sjljehprepare.
  • initialize SjljEHPrepare pass with CodeGen library.
  • rebased
  • added test (32bit on X86, 64bit on VE).
Feb 18 2020, 4:41 AM · Unknown Object (Project), Restricted Project
simoll added a parent revision for D74718: [VE] TLS codegen: D71338: [VE,#1] Scalar code generation.
Feb 18 2020, 1:28 AM · Restricted Project, Unknown Object (Project)
simoll added a child revision for D71338: [VE,#1] Scalar code generation: D74718: [VE] TLS codegen.
Feb 18 2020, 1:28 AM · Unknown Object (Project), Restricted Project
simoll updated the diff for D74718: [VE] TLS codegen.
  • rebased
  • typos
Feb 18 2020, 1:28 AM · Restricted Project, Unknown Object (Project)

Feb 17 2020

simoll created D74718: [VE] TLS codegen.
Feb 17 2020, 7:46 AM · Restricted Project, Unknown Object (Project)
simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
  1. Rename to llvm.experimental.vp.* - Inserting experimental is the preferred way to introduce new intrinsics until they are stable (for technical reasons brought up by @chandlerc - https://reviews.llvm.org/D69891#1852795 ).

I feel like I should mention that I don't know how Chandler feels about the use of "experimental" for these intrinsics. I wasn't trying to claim his approval of my suggestion, merely explaining that I thought the reasoning that led to the current naming of the constrained FP intrinsics probably applied here as well.

Well, to set this straight, i didn't mean to imply Chandler's approval. I just want to document what motivates the experimental prefix.

Feb 17 2020, 1:08 AM · Restricted Project

Feb 14 2020

simoll committed rG60431bd728f7: [VE] Support for PIC (global data and calls) (authored by kaz7).
[VE] Support for PIC (global data and calls)
Feb 14 2020, 12:51 AM
simoll closed D74536: [VE] Support for PIC (global data and calls).
Feb 14 2020, 12:50 AM · Restricted Project, Unknown Object (Project)
simoll updated the diff for D74536: [VE] Support for PIC (global data and calls).
  • rebased
  • coding standard
  • newline
Feb 14 2020, 12:50 AM · Restricted Project, Unknown Object (Project)
simoll planned changes to D74536: [VE] Support for PIC (global data and calls).
  • API change EmitInstruction -> emitInstruction
  • following coding standard for all new functions (EmitSIC -> emitSIC)
Feb 14 2020, 12:50 AM · Restricted Project, Unknown Object (Project)

Feb 13 2020

simoll updated the diff for D74536: [VE] Support for PIC (global data and calls).

unsigned -> Register

Feb 13 2020, 8:42 AM · Restricted Project, Unknown Object (Project)
simoll updated the diff for D74536: [VE] Support for PIC (global data and calls).
  • rebased
  • addressed comments
Feb 13 2020, 8:33 AM · Restricted Project, Unknown Object (Project)
simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

Ok. This is a summary of the requested changes and i'd like to get your go ahead before "committing" them to the patch:

  1. Define what 'W' is (that is the vector length that %evl is compared against) - for static vector types this would be the number of elements of the vector, for scalable types W == MVL and the target is responsible for defining MVL.

I object. The only sensible definition for the upper bound on %evl is the number of elements in the vector type in question (because %evl counts vector elements). We already have a concept of "number of elements in a vector type" that generalizes across all vector types (fixed-width and scalable), and it is quite target-independent: <vscale x $N x $elemtype > (where $N is a constant) has vscale * $N elements. The only target-dependent part is in the positive integer vscale, and its behavior is quite restricted. All of this is already stated in the LangRef (in the section on vector types), and there is no reason for VP intrinsics to repeat it, let alone deviate from it by e.g. introducing new terminology (MVL) or making provisions for more target-dependent behavior than actually exists. The VP instructions should just define their behavior in terms of the number of elements in the vector.

+1
I was complicating things. MVL == number of vector elements and the whole discussion about what MVL is and how it is read/set really is part of the scalable type/vscale discussion.

Feb 13 2020, 2:23 AM · Restricted Project
simoll created D74536: [VE] Support for PIC (global data and calls).
Feb 13 2020, 2:12 AM · Restricted Project, Unknown Object (Project)

Feb 12 2020

simoll added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

i have a suggestion. for SimpleV we.definitely need to have an explicit way to specify MVL. this because it is literally specifying precisely how many scalar registers are to be allocated for a vector op.

Would it work for you if we leave the definition of MVL for scalable types to the targets?

mmm... honestly? probably not. however we can get away with either inline assembler (for a very limited subset of requirements) or just going "y'know what, let's just set MVL hard-coded to default to 4 or 8 for all loops", for now, as best matched to the (planned) maximum internal register read/write ports for our first chip.

I think i wasn't clear: what i meant to say is that we will not decide how MVL is defined/queried/set in the scope of this RFC... potentially leading to the situation that every target comes with its own set of target intrinsics to do so.

Feb 12 2020, 7:55 AM · Restricted Project
simoll added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

The up-to-date list of planned changes (also for this patch) is here: https://reviews.llvm.org/D69891#1871485

Feb 12 2020, 1:02 AM · Restricted Project
simoll added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

i have a suggestion. for SimpleV we.definitely need to have an explicit way to specify MVL. this because it is literally specifying precisely how many scalar registers are to be allocated for a vector op.

Would it work for you if we leave the definition of MVL for scalable types to the targets?

Feb 12 2020, 1:02 AM · Restricted Project
simoll planned changes to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

Ok. This is a summary of the requested changes and i'd like to get your go ahead before "committing" them to the patch:

Feb 12 2020, 12:43 AM · Restricted Project
simoll committed rG42a16dacda41: [VE] Bit operator isel (authored by kaz7).
[VE] Bit operator isel
Feb 12 2020, 12:07 AM
simoll closed D74304: [VE] Bit operator isel.
Feb 12 2020, 12:06 AM · Restricted Project, Unknown Object (Project)

Feb 11 2020

simoll updated the diff for D74304: [VE] Bit operator isel.
  • Use i32 promotion for bitreverse
Feb 11 2020, 8:36 AM · Restricted Project, Unknown Object (Project)

Feb 10 2020

simoll created D74304: [VE] Bit operator isel.
Feb 10 2020, 2:31 AM · Restricted Project, Unknown Object (Project)
simoll committed rGc49b9e0d3284: [Doc] Proposal for vector predication (authored by simoll).
[Doc] Proposal for vector predication
Feb 10 2020, 1:37 AM
simoll closed D73889: [Doc] Proposal for vector predication.
Feb 10 2020, 1:36 AM · Restricted Project

Feb 6 2020

simoll updated the diff for D73889: [Doc] Proposal for vector predication.

Formatted to 80 characters per line max

Feb 6 2020, 12:56 AM · Restricted Project
simoll added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

OK. I was picturing MVL as some sort of maximum supported by the hardware in some sense or context. I think(?) I've got it now.

So let me ask about how you're picturing this working on targets that don't support these non-fixed vector lengths. The comments from lkcl have me concerned that we're going to be asked to emulate this behavior, which is possible I suppose but probably not the best choice performance wise. Consider this call:

%sum = call <8 x double> @llvm.vp.fadd.f64(<8 x double> %x,<8 x double> %y, <8 x i1> %mask, i32 4)

Frankly, I'd hope never to see such a thing. We talked about using -1 for the %evl argument for targets that don't support variable vector length (is that the right phrase?), but what are we supposed to do if something else is used?

For targets that do not support %evl they can say so through TTI and the ExpandVectorPredicationPass will convert it into:

Feb 6 2020, 12:21 AM · Restricted Project

Feb 4 2020

simoll committed rG3ed12232b037: [VE] half fptrunc+store&load+fpext (authored by kaz7).
[VE] half fptrunc+store&load+fpext
Feb 4 2020, 8:23 AM
simoll closed D73899: [VE] half fptrunc+store&load+fpext.
Feb 4 2020, 8:22 AM · Restricted Project, Unknown Object (Project)
simoll added a comment to D73899: [VE] half fptrunc+store&load+fpext.

thx!

Feb 4 2020, 8:22 AM · Restricted Project, Unknown Object (Project)
simoll updated the diff for D73899: [VE] half fptrunc+store&load+fpext.
  • formatting (lint)
  • rebased
Feb 4 2020, 5:37 AM · Restricted Project, Unknown Object (Project)
simoll added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

Exactly. The VE target strictly requires VL <= MVL or you'll get a hardware exception. Enforcing strict UB here means VP-users have to explicitly drop instructions that keep the VL within bounds. This means that we can optimize the VL computation code and that it can be factored into cost calculations, etc. With Options 2 & 3 this would happen only very late in the backend when most scalar optimizations are already done.

I think I'm lost here. Which thing is VL and which is MVL in this scenario?

VL == %evl
MVL == W
Sorry for the vector speak :)

Feb 4 2020, 2:29 AM · Restricted Project
simoll added a comment to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.

I'm not entirely clear where this value comes from, but it seems like whatever generated it must know that we're generating SVE code, right?

This is not architecture specific, and thus this is not assuming SVE. In the case of SVE, the vector length is unknown at compile time (it is a multiple of something), and constant at run-time. In the RISC-V vector extension, I believe it can be changed at any point. Thus, the way to obtain this value is by reading/writing a status register, or something similar, but relying on querying the architecture features. And whether it is constant at runtime, or can be changed at any point, this API seems to cover the different cases.

Alright, I was reaching for a more general concept that I obviously don't know the term for. What I meant to say was just that whatever generated the argument must know something specific about the target architecture.

Operand bundles are not the same as optional parameters. Operand bundles pessimistically imply side-effects where as a plain i32 argument is innocuous to optimizations:

https://llvm.org/docs/LangRef.html#operand-bundles

  • Calls and invokes with operand bundles have unknown read / write effect on the heap on entry and exit (even if the call target is readnone or readonly), unless they’re overridden with callsite specific attributes.

That is reasonable for constrained fp intrinsics, which always have such a dependence. Many VP intrinsics however do not have any side effects or only inspect/modify memory through their pointer arguments, etc.

We could add a callsite attribute when the intrinsic is created. We have that information about the intrinsic, right?

I'll admit that there may be no practical difference between what you've proposed and what I have in mind (in the abstract sense that assumes it's even possible to implement this in the way that I'm imagining). Mostly, I'm trying to explore what I perceive to be a bad smell in the IR. Having a parameter that is irrelevant for some targets just doesn't seem right. Introducing these intrinsics with "experimental" in the name would make me feel a bit better about that, even though again it has no practical effect.

The real question is, do targets without native support for EVL have anything to gain from making the argument optional?

I'm not sure I agree that is the real question. What is gained by not having the floating point constraint arguments always present even when they aren't needed? We have values that describe the default mode, so we could use those when we want the default mode. I think we all agree that they shouldn't be there when we don't need them, yet I would argue that those arguments are more relevant when "not needed" than the evl argument is.

I'm imagining walking someone through the IR, explaining what each instruction means. I'd be a bit embarrassed when I get to a vp intrinsic and say, "Ignore the last argument. We don't use it for this target."

But like I said above, this is much more a vague indication to me that we haven't got this right yet than a concrete problem.

To me all of this points in the direction that we'd want a standard mechanism for optional parameters. We have three options for this right now:
a) Come up with a novel, clean slate scheme for optional parmeters with default values (eg constrained fp default fp env values, i32 -1 for VP intrinsics). Some examples:

Feb 4 2020, 2:20 AM · Restricted Project

Feb 3 2020

simoll created D73899: [VE] half fptrunc+store&load+fpext.
Feb 3 2020, 8:28 AM · Restricted Project, Unknown Object (Project)
simoll committed rGbe9fe6aa8bd5: [VE] (fp)trunc+store & load+(fp)ext isel (authored by kaz7).
[VE] (fp)trunc+store & load+(fp)ext isel
Feb 3 2020, 8:11 AM
simoll closed D73774: [VE] (fp)trunc+store & load+(fp)ext isel.
Feb 3 2020, 8:11 AM · Restricted Project, Unknown Object (Project)
simoll committed rG07c9f7574d68: [VE] vaarg functions callers and callees (authored by kaz7).
[VE] vaarg functions callers and callees
Feb 3 2020, 7:44 AM
simoll closed D73710: [VE] vaarg functions callers and callees.
Feb 3 2020, 7:44 AM · Restricted Project, Unknown Object (Project)
simoll updated the diff for D73710: [VE] vaarg functions callers and callees.
  • addressed formatting issues
Feb 3 2020, 7:43 AM · Restricted Project, Unknown Object (Project)
simoll added a parent revision for D73889: [Doc] Proposal for vector predication: D57504: RFC: Prototype & Roadmap for vector predication in LLVM.
Feb 3 2020, 6:50 AM · Restricted Project
simoll added a child revision for D57504: RFC: Prototype & Roadmap for vector predication in LLVM: D73889: [Doc] Proposal for vector predication.
Feb 3 2020, 6:50 AM · Restricted Project
simoll added a comment to D73889: [Doc] Proposal for vector predication.

I probably did not add everybody who should be reviewing or at least be aware of this. Feel free to add folks to make sure we get wide community agreement going forward.

Feb 3 2020, 6:50 AM · Restricted Project
simoll created D73889: [Doc] Proposal for vector predication.
Feb 3 2020, 6:28 AM · Restricted Project