search for: i1024

...g code generation and backing them with LLVM's arbitrary ints. This required inferring the resulting type (and its modulus) and just plugging it in to modexp1024, modmul... Here's an excerpt of the generated LLVM IR from the frontend: ; ModuleID = 'Prover' @_s_1 = external global i1024 @_r_1 = external global i1024 declare i1024 @Random() declare i1024 @modadd1024(i1024, i1024, i1024) declare i1024 @modsub1024(i1024, i1024, i1024) declare i1024 @modmul1024(i1024, i1024, i1024) declare i1024 @modexp1024(i1024, i1024, i1024) declare i1 @Verify(i1) define void @Round0() { ent...

...the compiler itself? Reid is talking about > how the compiler itself is implemented, I was describing how the generated > code works. Generated code. So the memory used for the integer at program runtime is inlined into the allocation point then? So if I define a local variable of type 'i1024', it will allocate a block of 1024 bits on the stack, if I define a struct with an i1024, it will be in the struct itself, etc. Is there anyone working on complete support for this in the code generators? Sandro

On Mon, 18 Jun 2007, Sandro Magi wrote: > Generated code. So the memory used for the integer at program runtime > is inlined into the allocation point then? So if I define a local > variable of type 'i1024', it will allocate a block of 1024 bits on the > stack, if I define a struct with an i1024, it will be in the struct > itself, etc. Yes, exactly. > Is there anyone working on complete support for this in the code generators? Nope, not that I know of. -Chris -- http://nondot.org/s...

Chris Lattner wrote: >On Mon, 18 Jun 2007, Sandro Magi wrote: > > >>Generated code. So the memory used for the integer at program runtime >>is inlined into the allocation point then? So if I define a local >>variable of type 'i1024', it will allocate a block of 1024 bits on the >>stack, if I define a struct with an i1024, it will be in the struct >>itself, etc. >> >> > >Yes, exactly. > > Unless something has changed recently, both of these i1024 examples will generate an assertio...

...> missing many opportunities. > - It splits based the underlying type of the alloca, regardless of how the > alloca is accessed. > - When the splitting fails (often due to thresholds), the vector-value > conversion kicks in for preposterous cases to form "bit vectors" with i1024 > and other large types. > > Let's talk about the i1024 stuff first. This is actually what motivated me > to start looking at this space. There are a few PRs about how this causes > the backend to essentially give up and go home. In many other cases, such > as essentially ever...

...d be any different then passing in a null > pointer or garbage pointer into an API that would then bus error. Besides invalid IR, codegen also uses abort and assert when it encounters valid and Verifier-clean IR that uses features that codegen does not suport, due to missing functionality (e.g. i1024) or due to target-specific limitations (e.g. x86_f80 on non-x86 targets). Currently there no way to recover if the IR contains some construct that codegen can't handle. This is unfortunate for some applications. Dan

On Mon, 18 Jun 2007, Sandro Magi wrote: > Ok, so if I needed very precise control over the allocation of memory, > then I should avoid using integers with bit widths larger than 64 bits > (or perhaps 128)? Is there a hard rule for an integer being stack > allocated, ie. one that doesn't depend on the current implementation > details? In the generated code, or in the compiler

...a >> null >> pointer or garbage pointer into an API that would then bus error. > > Besides invalid IR, codegen also uses abort and assert when it > encounters valid and Verifier-clean IR that uses features that > codegen does not suport, due to missing functionality (e.g. i1024) > or due to target-specific limitations (e.g. x86_f80 on non-x86 > targets). There are also some cases with inline asm that do the same thing. > Currently there no way to recover if the IR contains some > construct that codegen can't handle. This is unfortunate for some > appl...

Ok, so if I needed very precise control over the allocation of memory, then I should avoid using integers with bit widths larger than 64 bits (or perhaps 128)? Is there a hard rule for an integer being stack allocated, ie. one that doesn't depend on the current implementation details? Sandro On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Sandro Magi wrote: > >

...) on SX-Aurora, which may > be represented as: > > <scalable 256 x double> llvm.evl.gather.nxv16f64(<scalable 16 x double*> %Ptr, <scalable 16 x i1> mask %M, i32 vlen 16) > > In contrast to the above I can't very well say one should write this as a gather of i1024, but it also seems like a rather specialized instruction (presumably used for blocked processing of matrices?) so I can't say that this on its own motivates me to complicate a proposed core IR construct. Cheers, Robin -------------- next part -------------- An HTML attachment was scrubbed... U...

On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Simon Moll <moll at cs.uni-saarland.de> writes: > > > You are referring to the sub-vector sizes, if i am understanding > > correctly. I'd assume that the mask sub-vector length always has to be > > either 1 or the same as the data sub-vector length. For example,