[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64.

hjl.tools added a comment. In https://reviews.llvm.org/D53919#1282692, @efriedma wrote: > As far as I know, according to the ABI docs, it's impossible to return a > 256-bit vector from a function if AVX is disabled. > > Given that we aren't rejecting the testcase, we're effectively implementing

[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64.

hjl.tools added a comment. In https://reviews.llvm.org/D53919#1282734, @efriedma wrote: > Whatever you call it, the question remains; what specification and/or > compiler are we trying to be compatible with? The ABI before AVX was introduced. Repository: rC Clang

[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64.

hjl.tools added a comment. In https://reviews.llvm.org/D53919#1282952, @efriedma wrote: > With both 3.3 and trunk (I don't have a 7.0 handy; I can build it if it would > be helpful): Please try clang 2.6 on both testcases. Repository: rC Clang https://reviews.llvm.org/D53919

[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64.

hjl.tools added a comment. In https://reviews.llvm.org/D53919#1282748, @efriedma wrote: > The ABI document before AVX was introduced didn't say anything at all about > 256-bit vectors. So we're talking about compatibility with some other > compiler. Which compiler? X86-64 compilers created

[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64.

hjl.tools added a comment. In https://reviews.llvm.org/D53919#1282811, @efriedma wrote: > No, AVX512 wasn't even announced when clang 3.3 came out. Try this with clang 3.3 and clang 7.0. [hjl@gnu-cfl-1 tmp]$ cat z.c typedef int __attribute__((mode(SI))) si; typedef si

[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64.

hjl.tools added a comment. In https://reviews.llvm.org/D53919#1282797, @efriedma wrote: > I just tried clang 3.3, and as far as I can tell it behaves the same way as > trunk. > > If the argument is that we should be compatible with gcc on Linux, that's > fine, but we should explicitly state

[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value.

hjl.tools added inline comments. Comment at: lib/CodeGen/TargetInfo.cpp:2862 // place naturally. - if (!isAggregateTypeForABI(Ty)) { + if (!isAggregateTypeForABI(Ty) && !IsIllegalVectorType(Ty)) { // Treat an enum type as its underlying type. Doesn't

[PATCH] D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64.

hjl.tools added a comment. In https://reviews.llvm.org/D53919#1287510, @echristo wrote: > In https://reviews.llvm.org/D53919#1282994, @hjl.tools wrote: > > > In https://reviews.llvm.org/D53919#1282952, @efriedma wrote: > > > > > With both 3.3 and trunk (I don't have a 7.0 handy; I can build it

[PATCH] D79617: Add cet.h for writing CET-enabled assembly code

hjl.tools added a comment. In D79617#2045552 , @rsmith wrote: > I would like a specification for this header to be added somewhere. We > shouldn't be implementing random things with no specification. (Suppose > someone claims that our `` is wrong in

[PATCH] D105462: [X86] Add CRC32 feature.

hjl.tools added inline comments. Comment at: llvm/lib/Target/X86/X86.td:84 "Enable SSE 4.2 instructions", - [FeatureSSE41]>; + [FeatureSSE41, FeatureCRC32]>; // The

[PATCH] D105462: [X86] Add CRC32 feature.

hjl.tools added inline comments. Comment at: llvm/lib/Target/X86/X86.td:84 "Enable SSE 4.2 instructions", - [FeatureSSE41]>; + [FeatureSSE41, FeatureCRC32]>; // The

[PATCH] D99708: [X86] Enable compilation of user interrupt handlers.

hjl.tools added a comment. In D99708#2664076 , @LuoYuanke wrote: > In D99708#2663989 , @craig.topper > wrote: > >> A user interrupt is different than a regular interrupt right? It doesn't >> make sense that we

[PATCH] D99708: [X86] Enable compilation of user interrupt handlers.

hjl.tools added a comment. In D99708#2664218 , @craig.topper wrote: > In D99708#2664164 , @hjl.tools wrote: > >> In D99708#2664076 , @LuoYuanke >> wrote: >> >>> In

[PATCH] D99708: [X86] Enable compilation of user interrupt handlers.

hjl.tools added a comment. In D99708#2664372 , @craig.topper wrote: > In D99708#2664351 , @hjl.tools wrote: > >> In D99708#2664218 , @craig.topper >> wrote: >> >>> In

[PATCH] D105462: [X86] Add CRC32 feature.

hjl.tools added inline comments. Comment at: llvm/lib/Support/X86TargetParser.cpp:531 constexpr FeatureBitset ImpliedFeaturesSSSE3 = FeatureSSE3; constexpr FeatureBitset ImpliedFeaturesSSE4_1 = FeatureSSSE3; constexpr FeatureBitset ImpliedFeaturesSSE4_2 = FeatureSSE4_1;

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

hjl.tools added a comment. >> The choice that high bits are unspecified rather than extended is an >> interesting one. Can you speak to that? That's good for +, -, *, &, |, ^, >> <<, and narrowing conversions, but bad for ==, <, /, >>, and widening >> conversions. > > I've added @hjl.tools

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

hjl.tools added a comment. In D108643#2999724 , @aaron.ballman wrote: > In D108643#2991995 , @hjl.tools > wrote: > The choice that high bits are unspecified rather than extended is an interesting

[PATCH] D105462: [X86] Add CRC32 feature.

hjl.tools added inline comments. Comment at: clang/lib/Basic/Targets/X86.cpp:159 + // Enable CRC32 if SSE4.2 is enabled. + // NOTE: In conformance with GCC behavior, CRC32 is still available even if + // it's explicitly disabled. tianqing wrote: >

[PATCH] D105462: [X86] Add CRC32 feature.

hjl.tools added inline comments. Comment at: clang/lib/Basic/Targets/X86.cpp:159 + // Enable CRC32 if SSE4.2 is enabled. + // NOTE: In conformance with GCC behavior, CRC32 is still available even if + // it's explicitly disabled. craig.topper wrote: >

[PATCH] D122789: [compiler-rt] [scudo] Use -mcrc32 on x86 when available

hjl.tools added a comment. In D122789#3447413 , @pengfei wrote: > In D122789#3446865 , @MaskRay wrote: > >> To kurly (original Gentoo reporter): >> >> printf '#include \n#include \nuint32_t >>