search for: 1ll

Vladimir Prus wrote: > Vladimir Prus wrote: > > The above-mentioned test contains this: > > > > long B53 = - (1LL << 53); > > > > strictly speaking, this is not correct code. The C standard says about > > shift: "if the value of the first operator is ... or greater than ... the > > width of the promoted left operand, the behaviour is underfined". > > Forget this, I...

The above-mentioned test contains this: long B53 = - (1LL << 53); strictly speaking, this is not correct code. The C standard says about shift: "if the value of the first operator is ... or greater than ... the width of the promoted left operand, the behaviour is underfined". Thouhts? - Volodya

On Thu, 2004-07-08 at 07:07, Vladimir Prus wrote: > Vladimir Prus wrote: > > Vladimir Prus wrote: > > > The above-mentioned test contains this: > > > > > > long B53 = - (1LL << 53); > > > > > > strictly speaking, this is not correct code. The C standard says about > > > shift: "if the value of the first operator is ... or greater than ... the > > > width of the promoted left operand, the behaviour is underfined". >...

...or you describe above, it looks like sizeof applied to a pointer (and to size_t etc.) isn't a constant expression in SPIR's model. Another factor to consider, with size_t etc as defined in SPIR, is the usual arithmetic conversions. For instance (assuming a 64-bit long long), sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and would be unsigned if size_t is 64 bits wide. How is this handled? [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of the host/device bitness. So this would follow the normal integer promotion rules. How do you perform record...

Vladimir Prus wrote: > The above-mentioned test contains this: > > long B53 = - (1LL << 53); > > strictly speaking, this is not correct code. The C standard says about > shift: "if the value of the first operator is ... or greater than ... the > width of the promoted left operand, the behaviour is underfined". Forget this, I've missed the 'LL...

...n > > On Wed, Sep 12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > Another factor to consider, with size_t etc as defined in SPIR, is > the usual > > arithmetic conversions. For instance (assuming a 64-bit long long), > > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and > would be > > unsigned if size_t is 64 bits wide. How is this handled? > > > > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of > the > > host/device bitness. So this would follow the normal in...

On Wed, Sep 12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Another factor to consider, with size_t etc as defined in SPIR, is the usual > arithmetic conversions. For instance (assuming a 64-bit long long), > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and would be > unsigned if size_t is 64 bits wide. How is this handled? > > [Villmow, Micah] OpenCL C defines ‘int’ to be 32bits irrespective of the > host/device bitness. So this would follow the normal integer promotion > rules. I think y...

...nsn, unsigned startBit, unsigned numBits) { assert(startBit + numBits <= (sizeof(InsnType)*8) && "Instruction field out of bounds!"); InsnType fieldMask; if (numBits == sizeof(InsnType)*8) fieldMask = (InsnType)(-1LL); else fieldMask = ((1 << numBits) - 1) << startBit; return (insn & fieldMask) >> startBit; } may fail if the last parameter "startBit" is larger than 31 which is likely to occur when instruction sets have encodings more than 32 bits. In "else&qu...

Alkis Evlogimenos wrote: > > But the test still has a problem ;-) > > > > printf("%ld\n", Arg / (1LL << 4)); > > > > Again, the passed value is long long, and format specifier is '%ld'. What > > about the attached patch? > > I think testL has another problem. It takes a long argument which in C I > think is a 4-byte int, right? Yes, but I don't underst...

...58 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> > wrote: > > Another factor to consider, with size_t etc as defined in SPIR, is > the usual > > arithmetic conversions. For instance (assuming a 64-bit long long), > > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and > would be > > unsigned if size_t is 64 bits wide. How is this handled? > > > > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of > the > > host/device bitness. So this would follow the normal in...

On Tue, Jul 26, 2011 at 11:35 AM, Taral <taralx at gmail.com> wrote: > > One piece of code I'm writing has a lot of intermediates, and I'm > trying to optimize down the number of memory accesses. Here's a > snippet from the start of the function, where I think there is some > low-hanging fruit: > > # BB#0: >        pushq   %rbp >        pushq   %r15

One piece of code I'm writing has a lot of intermediates, and I'm trying to optimize down the number of memory accesses. Here's a snippet from the start of the function, where I think there is some low-hanging fruit: # BB#0: pushq %rbp pushq %r15 pushq %r14 pushq %r13 pushq %r12 pushq %rbx movq %rdx, %rcx movq %rdi, -16(%rsp) # 8-byte Spill movq (%rsi), %rdi movq

...12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com> > > wrote: > > > Another factor to consider, with size_t etc as defined in SPIR, is > > the usual > > > arithmetic conversions. For instance (assuming a 64-bit long long), > > > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and > > would be > > > unsigned if size_t is 64 bits wide. How is this handled? > > > > > > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of > > the > > > host/device bitness. So t...

...Micah > <Micah.Villmow at amd.com> > >> wrote: > >> > Another factor to consider, with size_t etc as defined in SPIR, is > >> the usual > >> > arithmetic conversions. For instance (assuming a 64-bit long > long), > >> > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and > >> would be > >> > unsigned if size_t is 64 bits wide. How is this handled? > >> > > >> > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective > of > >> the > >> &...

...int cpu_num) +{ + u64 new_mult, curr_tsc; + s8 new_shift; + struct cpu_time *t; + + t = &this_cpu(cpu_time); + new_mult = info->tsc_to_system_mul; + do_div(new_mult, new / 1000); + new_mult *= (old / 1000); + new_shift = info->tsc_shift; + while (new_mult > (1LL <<32)) { + new_shift += 1; + new_mult = new_mult >> 1; + } + while (new_mult < (1LL << 31)) { + new_shift -= 1; + new_mult = new_mult << 1; + } + + t->tsc_scale.mul_frac = new_mult; + t->tsc_scale.shift = new_shift; + l...

...Sep 12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com> >> wrote: >> > Another factor to consider, with size_t etc as defined in SPIR, is >> the usual >> > arithmetic conversions. For instance (assuming a 64-bit long long), >> > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and >> would be >> > unsigned if size_t is 64 bits wide. How is this handled? >> > >> > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of >> the >> > host/device bitness. So this wo...

...12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com> > > wrote: > > > Another factor to consider, with size_t etc as defined in SPIR, is > > the usual > > > arithmetic conversions. For instance (assuming a 64-bit long long), > > > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and > > would be > > > unsigned if size_t is 64 bits wide. How is this handled? > > > > > > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of > > the > > > host/device bitness. So t...

...lmow at amd.com> >> >> wrote: >> >> > Another factor to consider, with size_t etc as defined in SPIR, is >> >> the usual >> >> > arithmetic conversions. For instance (assuming a 64-bit long >> long), >> >> > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and >> >> would be >> >> > unsigned if size_t is 64 bits wide. How is this handled? >> >> > >> >> > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective >> of >> >...

...; uint128_t m = (uint128_t) x->l[i_] * (y->l[j_] * (i + j > 4 ? 19 : 1)); if (i + j > 4) { t[i + j - 5] += m; } else { t[i + j] += m; } } #define LOOP(i) BODY(i, 0); BODY(i, 1); BODY(i, 2); BODY(i, 3); BODY(i, 4); LOOP(0); LOOP(1); LOOP(2); LOOP(3); LOOP(4); const uint64_t mask = (1LL << 51) - 1; for (int i = 0; i < 5; i++) { r->l[i] = ((uint64_t) t[i] & mask) + (i == 0 ? 19 : 1) * (uint64_t)(t[(i + 4) % 5] >> 51); } } % clang -O4 -S -o f.l f.c If you change the loop to the unrolled version: #define FOLD1(i) r->l[i] = ((uint64_t) t[i] & m...

...ure this > is so. E-mail is not a 100% secure communications medium. We recommend > you observe this when e-mailing us. > *Esendex Ltd* is a limited company registered in the UK, with company > number 04217280 and having its registered office at 32a Stoney Street ? > Nottingham ? NG1 1LL ? United Kingdom. > [v1.1 EN]