In D120327#3493181, @mgehre-amd wrote:

In D120327#3492053, @efriedma wrote:

Instead of putting the __divmodei5/__udivmodei5 routines in compiler-rt, can we just make the backend embed them into the object file?

I agree for smaller builtin function. Here, I would need to check how much LLVM IR is necessary.

looks good to me! you may want someone else to also approve this since I am not a regular LLVM contributor.

In D120327#3399900, @erichkeane wrote:

This sounds like a really good idea to me. The LLVM code generation "Knows" how big this value needs to be and can do it on the stack of the caller. So it would generate IR the equivalent of:

...

Right?

In D120327#3398754, @FreddyYe wrote:

So everyone is OK with use malloc(), right? That was my biggest concern.

In D120327#3396605, @mgehre-amd wrote:

Hey, yes it's still near the top of my TODO list. Had a few other things to do, but I'm planning to come back to this.

I was thinking how to properly test that my fixed version would work fine in big endian - any idea?

In D120327#3339898, @mgehre-amd wrote:

In D120327#3338323, @programmerjake wrote:

As far as I can tell, this code seems to assume it's running on a little-endian system. I think it needs to correctly handle what happens when bigints are stored in the other endian (where the first word is the most-significant).

Yes, that's a good observation. I don't have access to a big-endian system right now. Should I disable building those functions on big-endian systems for this PR?

As far as I can tell, this code seems to assume it's running on a little-endian system. I think it needs to correctly handle what happens when bigints are stored in the other endian (where the first word is the most-significant).

As far as I can tell, this implemention incorrectly returns overflow for 32-bit time_t for 00:00:08 UTC Jan 1 2038 since you forgot to check that the month, day, hour, and minute are equal to the 32-bit overflow time before checking that the seconds overflow. likewise for day, hour and minute.

In D57504#1857309, @programmerjake wrote:

From what I recall, the plan is to implement this by using fixed-size vector types combined with VL-based ops. MVL would be the size of those vector types.

From what I recall, the plan is to implement this by using fixed-size vector types combined with VL-based ops. MVL would be the size of those vector types.

In D57504#1853802, @rkruppe wrote:

In D57504#1853671, @programmerjake wrote:

We (Libre-SoC, provisionally renamed from Libre-RISCV) are currently building a processor that supports variable-length vector operations by having each operation specify the starting register in a flat register file, then relying on VL telling it how many elements to operate on, which, when divided by the number of elements per register, directly translates to the number of registers to operate on. So, if VL is out of bounds, the instructions can overwrite registers past the end of the range assigned by the register allocator and/or trap. This would probably force use of option #1 above, at least for our processor. Our ISA design is still incomplete, so we might add (or already have) a mechanism allowing use of option #2 or #3 if there is a sufficient reason (will have to see what the rest of Libre-SoC think).

Presumably you have an efficient way to somehow force the VL into the intended range to support strip-mining of loops? The exact strategy doesn't matter, anything that avoids VL being "out of bounds" should make the other options work just fine. (Assuming there aren't other, larger problems with mapping VP operations to your ISA.)

In D57504#1853591, @rkruppe wrote:

(This was gonna be an inline comment on D69891, but it's more of a general conceptual issue, so I decided to move it here.)

Right now, LangRef changes in D69891 describe the restriction on the EVL value as this:

The explicit vector length (%evl) is only effective if it is non-negative, and when that is the case, its value is in the range:

0 <= %evl <= W,   where W is the vector length.

The restriction is good, but this wording doesn't specify what happens when %evl is not in that range. Some sort of undefined behavior, I assume, but this must be explicitly stated, especially since there are many ways in which it could be undefined. I don't recall previous discussion of this detail and I don't know what you have in mind, but some possibilities I see:

1. The instruction has capital-UB undefined behavior. This gives the greatest flexibility to backends (e.g., allows generation of code that traps if %evl is too large) but I don't know of any architecture that needs this much flexibility and it constrains IR optimizations (code hoisting etc.) the most.
2. The instruction returns poison (i.e., all result lanes are poison) and all lanes are (potentially, non-deterministically) enabled regardless of the mask parameter. This is less restrictive for IR optimizations (e.g., integer vp.add can unconditionally be speculated) but still allows backends to unconditionally use SETVL-style "stripmining" instructions that are not generally consistent (across architectures) w.r.t. which lanes become active when a vector length greater than the hardware vector length is requested.
3. %EVLmask is undef, that's all. As consequence, lanes disabled by the %mask argument definitely stay disabled, but for other lanes (where the mask has a 1 or an undef) it's non-deterministic whether they are active. As far as I can see, this has pretty much the same implications for IR optimizations and backends (excluding hypothetical pathological architectures) but is less of a special case to specify and directly captures the diversity of hardware behavior that (presumably) motivates this restriction on EVL.

Off the cuff, I would suggest the last option.

The __GNUG__ macro is defined to be 4 rather than matching __GNUC__

Shouldn't __GNUG__ match __GNUC__?

We will also need to adjust gather/scatter and possibly other load/store kinds to allow the address vector length to be a divisor of the main vector length (similar to mask vector length). I didn't check if there are intrinsics for strided load/store, those will need to be changed too, to allow, for example, storing <scalable 3 x float> to var.v in: