[PATCH] D134788: [ARM64EC][clang-cl] Add arm64EC test; NFC

bcl5980 updated this revision to Diff 464909. bcl5980 retitled this revision from "[ARM64EC][clang-cl] Add /arm64EC flag" to "[ARM64EC][clang-cl] Add arm64EC test; NFC". CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134788/new/ https://reviews.llvm.org/D134788 Files: clang/test/Driver

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

bcl5980 added a comment. In D134788#3830987 , @efriedma wrote: > Missing testcase for the case where the warning is triggered? Based on David's comment I remove the test case with specified target. Not going to catch much in this change but if someone

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

This revision was automatically updated to reflect the committed changes. Closed by commit rGb0fff3db6ada: [ARM64EC][clang-cl] Add /arm64EC flag (authored by bcl5980). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134788/new/ https://reviews.llvm.or

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

bcl5980 marked 4 inline comments as done. bcl5980 added a comment. Thanks for the detail explaination. I agree that if the cost is the same hasArg is better to move to the first. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134788/new/ https://reviews.llvm.org/D134788 ___

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

bcl5980 added inline comments. Comment at: clang/lib/Driver/Driver.cpp:1384 + TC.getTriple().getSubArch() != llvm::Triple::AArch64SubArch_arm64ec) { +if (UArgs->hasArg(options::OPT__SLASH_arm64EC)) { + getDiags().Report(clang::diag::warn_target_override_arm64ec) ---

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

bcl5980 added a comment. In D134788#3823181 , @DavidSpickett wrote: > Has Microsoft documented this option? Not doubting it exists but I mostly see > how to use it rather than a specific page describing the option and its > behaviour. > > Not a big dea

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

bcl5980 updated this revision to Diff 464128. bcl5980 added a comment. address comments. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134788/new/ https://reviews.llvm.org/D134788 Files: clang/include/clang/Basic/DiagnosticDriverKinds.td clang/include/clang/Driver/Options.td clan

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

bcl5980 updated this revision to Diff 463746. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134788/new/ https://reviews.llvm.org/D134788 Files: clang/include/clang/Basic/DiagnosticDriverKinds.td clang/include/clang/Driver/Options.td clang/lib/Driver/Driver.cpp clang/test/Driver/c

[PATCH] D134788: [ARM64EC][clang-cl] Add /arm64EC flag

bcl5980 updated this revision to Diff 463744. bcl5980 added a comment. add warning when /arm64EC has been override CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134788/new/ https://reviews.llvm.org/D134788 Files: clang/include/clang/Basic/DiagnosticDriverKinds.td clang/include/clan

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added a comment. In D125418#3806720 , @efriedma wrote: >> Sometimes we will emit the alias here but later the function will be inlined >> or eliminated by DCE. > > If the alias is externally visible, it can't be eliminated; the compiler > can't

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added a comment. A question about the mangle and alias part. Should we move the code to create alias to backend also？Sometimes we will emit the alias here but later the function will be inlined or eliminated by DCE. And later we need to emit alias for direct call thunk also, like $origin

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added a comment. In D125418#3759174 , @efriedma wrote: > The reason struct returns require register shuffling is that AArch64 passes > the sret pointer in x8 (i.e. RAX), but the x64 calling convention expects in > in RCX (i.e. x0). So, for the

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added a comment. In D125418#3756223 , @efriedma wrote: > There's no way the calling convention can change based on whether you're > calling a function vs. a function pointer. I can't explain why MSVC is > generating different code. I think we

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added a comment. Another thing we need consider here is this case: #pragma pack(push, 1) struct b64 { char a[64]; }; #pragma pack(pop) typedef b64 (fptrtype)(int a); b64 f(void* p, int a) { return ((fptrtype*)p)(a); } For now we

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added inline comments. Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5128 +// to the function itself; it points to a stub for the compiler. +// FIXME: We also need to emit an entry thunk. +SmallString<256> MangledName; efriedma wrote: > bcl5

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added inline comments. Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5128 +// to the function itself; it points to a stub for the compiler. +// FIXME: We also need to emit an entry thunk. +SmallString<256> MangledName; efriedma wrote: > bcl5

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added inline comments. Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5128 +// to the function itself; it points to a stub for the compiler. +// FIXME: We also need to emit an entry thunk. +SmallString<256> MangledName; efriedma wrote: > bcl5

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

bcl5980 added inline comments. Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5128 +// to the function itself; it points to a stub for the compiler. +// FIXME: We also need to emit an entry thunk. +SmallString<256> MangledName; A headache thing here.