Displaying 7 results from an estimated 7 matches for "ui64".
Did you mean:
u64
2009 May 12
1
[LLVMdev] MSVC cstdint
...INT8_C(value) value##i8
# define INT16_C(value) value##i16
# define INT32_C(value) value##i32
# define INT64_C(value) value##i64
# define UINT8_C(value) value##ui8
# define UINT16_C(value) value##ui16
# define UINT32_C(value) value##ui32
# define UINT64_C(value) value##ui64
# define INTMAX_C(value) value##i64
# define UINTMAX_C(value) value##ui64
Which is more correct due to MSVC suffix (boost also defines
appropriate ones for appropriate compilers). My main thing is the
warnings, which were not there earlier, although I have had boost for
far longer. looking i...
2013 Oct 09
2
unsigned long long suffix
...r earlier versions, but if FLAC supports only
Visual Studio 2005 and newer, it's possible to reduce this code to:
#define FLAC__U64L(x) x##ULL
Another version:
/* adjust for compilers that can't understand using ULL suffix for uint64_t literals */
#ifdef _MSC_VER
#define FLAC__U64L(x) x##ui64
#else
#define FLAC__U64L(x) x##ULL
#endif
2016 May 02
3
[PATCH] MSVC2015U2 workaround, version 2
Here's a new version of a patch that fixes a problem with MSVC2105 update2,
but it doesn't disable any optimization, so the resulting encoding
performance should be almost unaffected by this workaround.
MSVC compiles
abs_residual_partition_sums[partition] = (FLAC__uint32)_mm_cvtsi128_si32(mm_sum);
into this:
movq QWORD PTR [rsi], xmm2
while it should be
movd
2016 Jun 28
2
[BUG] 3.8 alignment/struct padding
...// 1192
double, // 1200
double, // 1208
i8, // 1216
double, // 1224
float // 1232
}
The equivalent C struct:
typedef struct {
real32_T s;
real_T d;
int8_T i8[4];
uint16_T ui16[4];
int32_T i32[100];
uint64_T ui64[6];
int64_T i64[64];
char_T c[3];
creal_T mycomplex;
int32_T enumeration_int32;
int8_T enumeration_int8;
uint16_T enumeration_uint16;
cint32_T fixedpoint;
int32_T fixedpoint2;
int128m_T fimw[10];
real_T fisd1;
real_T fisd2;
real_T fisd3;
int8_T fisb;
real_T fid;
real32...
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
> Can you explain why you chose the approach of using a new pass?
> I pictured removing LegalizeDAG's type legalization code would
> mostly consist of finding all the places that use TLI.getTypeAction
> and just deleting code for handling its Expand and Promote. Are you
> anticipating something more
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 1:19 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> Per subject, this patch adding an additional pass to handle vector
>>
>> operations; the idea is that this allows removing the code from
>>
>> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
..._FP , MVT::i32 , Promote);
setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Expand);
} else {
- if (!UseSoftFloat && !NoImplicitFloat && X86ScalarSSEf64) {
+ if (!UseSoftFloat && X86ScalarSSEf64) {
// We have an impenetrably clever algorithm for ui64->double only.
setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Custom);
-
- // We have faster algorithm for ui32->single only.
- setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Custom);
} else {
- setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Promote);
+...