Markus Lindström via llvm-dev
2018-Jul-16 10:10 UTC
[llvm-dev] Target triple normalzation through the LLVM C API
Hello everyone, First of all, this is my first posting here, so feel free to tell me if I'm asking the wrong questions in the wrong place. I've discovered that the target triple normalization which used to be done at all times on sys::getDefaultTargetTriple() has been removed, due to the fact that most users of this function explicitly call Triple::normalize() on its result. This has however broken our compiler, which is built upon the LLVM C API, which relied on the default Windows target triple (x86_64-pc-win32 in our case) being normalized to x86_64-pc-windows-msvc. The breakage occurs because the X86 target lowering doesn't consider x86_64-pc-win32 to be an MSVC environment, and it doesn't lower a few instructions including SREM_I64 to MSVC equivalents (_allrem in this case; we end up with __moddi3 instead). I believe that we should fix this by allowing to invoke the target triple normalization function through the LLVM C API. I would suggest adding an LLVMNormalizeTriple function to the C API (in TargetMachine, I guess) which would wrap Triple::normalize(). Would this be the right way to go about it? If so, we'll propose a patch based on that idea. Thanks for your help, Markus Lindström, Raincode Labs (on behalf of LzLabs) E-mail markus at raincode.com
via llvm-dev
2018-Jul-16 17:44 UTC
[llvm-dev] Target triple normalzation through the LLVM C API
Hi Markus,> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Markus Lindström via llvm-dev > Sent: Monday, July 16, 2018 6:11 AM > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] Target triple normalzation through the LLVM C API > > Hello everyone, > > First of all, this is my first posting here, so feel free to tell me if > I'm asking the wrong questions in the wrong place.It's definitely the right place for this question.> > I've discovered that the target triple normalization which used to be done > at all times on sys::getDefaultTargetTriple() has been removed, due to the > fact that most users of this function explicitly call Triple::normalize() > on its result. This has however broken our compiler, which is built upon > the LLVM C API, which relied on the default Windows target triple (x86_64- > pc-win32 in our case) being normalized to x86_64-pc-windows-msvc. The > breakage occurs because the X86 target lowering doesn't consider x86_64- > pc-win32 to be an MSVC environment, and it doesn't lower a few > instructions including SREM_I64 to MSVC equivalents (_allrem in this case; > we end up with __moddi3 instead). > > I believe that we should fix this by allowing to invoke the target triple > normalization function through the LLVM C API. I would suggest adding an > LLVMNormalizeTriple function to the C API (in TargetMachine, I guess) > which would wrap Triple::normalize(). Would this be the right way to go > about it? If so, we'll propose a patch based on that idea.It seems quite reasonable to me. You might get different opinions when you post the patch, but it's a good place to start. Make sure to include 'whitequark' as a reviewer, code owner for the C API. --paulr> > Thanks for your help, > > Markus Lindström, Raincode Labs (on behalf of LzLabs) > E-mail markus at raincode.com > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Markus Lindström via llvm-dev
2018-Jul-17 07:17 UTC
[llvm-dev] Target triple normalzation through the LLVM C API
Hi Paul, Thanks for your quick feedback! I've introduced a diff on Phabricator with whitequark as a reviewer: https://reviews.llvm.org/D49414 Regards, Markus Lindström Raincode Labs (on behalf of LzLabs) -----Original Message----- From: paul.robinson at sony.com <paul.robinson at sony.com> Sent: Monday, July 16, 2018 19:45 To: Markus Lindström <Markus at raincode.com> Cc: llvm-dev at lists.llvm.org Subject: RE: Target triple normalzation through the LLVM C API Hi Markus,> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Markus Lindström via llvm-dev > Sent: Monday, July 16, 2018 6:11 AM > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] Target triple normalzation through the LLVM C API > > Hello everyone, > > First of all, this is my first posting here, so feel free to tell me > if I'm asking the wrong questions in the wrong place.It's definitely the right place for this question.> > I've discovered that the target triple normalization which used to be > done at all times on sys::getDefaultTargetTriple() has been removed, > due to the fact that most users of this function explicitly call > Triple::normalize() on its result. This has however broken our > compiler, which is built upon the LLVM C API, which relied on the > default Windows target triple (x86_64- > pc-win32 in our case) being normalized to x86_64-pc-windows-msvc. The > breakage occurs because the X86 target lowering doesn't consider > x86_64- > pc-win32 to be an MSVC environment, and it doesn't lower a few > instructions including SREM_I64 to MSVC equivalents (_allrem in this > case; we end up with __moddi3 instead). > > I believe that we should fix this by allowing to invoke the target > triple normalization function through the LLVM C API. I would suggest > adding an LLVMNormalizeTriple function to the C API (in TargetMachine, > I guess) which would wrap Triple::normalize(). Would this be the right > way to go about it? If so, we'll propose a patch based on that idea.It seems quite reasonable to me. You might get different opinions when you post the patch, but it's a good place to start. Make sure to include 'whitequark' as a reviewer, code owner for the C API. --paulr> > Thanks for your help, > > Markus Lindström, Raincode Labs (on behalf of LzLabs) E-mail > markus at raincode.com > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Possibly Parallel Threads
- [DebugInfo] DIBuilder missing interface to generate DWARF info for packed_decimal basic type.
- addition of vendor dwarf operator extension.
- [LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.
- addition of vendor dwarf operator extension.
- [DebugInfo] DIBuilder missing interface to generate DWARF info for packed_decimal basic type.