[llvm-dev] Target triple normalzation through the LLVM C API

[Markus Lindström via llvm-dev]

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