[LLVMdev] [cfe-dev] Handling SRet on Windows x86

Eli Bendersky eliben at google.com
Fri Mar 29 12:21:21 PDT 2013


On Fri, Mar 29, 2013 at 11:57 AM, Timur Iskhodzhanov <timurrrr at google.com>wrote:

> 2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>:
> >> How can having an MSVC compatible compiler be to the detriment of clang
> and
> >> llvm? No one is trying to break mingw here, merely add support for
> something
> > Just to make stuff clear: I just wanted proper naming which will be
> > non-confusing. Right now we have:
> >  - isTargetWindows() which really means "msvc-compabile"
> >  - isTargetWin32() which means "everything on windows", so Windows +
> > Mingw + Cygwin
> Minor correction: currently isTargetWin32 means 32-bits (not
> "everything"), Windows + Mingw, not Cygwin.
> So this is actually even more confusing...
>
> >  - isTargetWin64() is is basically 64-bit version of isTargetWin32(),
> > but strictly speaking is slightly different
> >
> > This naming while being the historical artifact is extremely
> > confusing. For me it seems the best solution will be something like
> > this:
> >  - isTargetMingw() - with obvious meaning
> >  - isTargetMSVC() - with obvious meaning
> >  - isTargetWindows() which will include all the flavours (so only OS
> > will matter here)
> >  - isTargetWindows() can be combined with existing 32/64 bit checks
> > This way we'll end with something being non-ambiguos.
> I think this is a much better naming than we have now, I'll prepare a
> patch for that.
>
> Should we change the ***-pc-win32 triple to ***-pc-msvc ?
>
>
I agree that explicitness is good here, and win32 *is* confusing when it
doesn't specify which compiler is meant. Of course the internal isTarget*()
APIs should be changed to match the chosen convention as well.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130329/24be2ea4/attachment.html>


More information about the llvm-dev mailing list