[cfe-commits] r68363 - in /cfe/trunk: include/clang/Basic/TargetInfo.h lib/Basic/Targets.cpp lib/CodeGen/CodeGenModule.cpp test/CodeGen/darwin-string-literals.c

[Daniel Dunbar]

Hi Eli,

On Thu, Apr 2, 2009 at 8:46 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Thu, Apr 2, 2009 at 5:57 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> > +  /// getUnicodeStringSymbolPrefix - Get the default symbol prefix to
> > +  /// use for string literals.
> > +  virtual const char *getUnicodeStringSymbolPrefix() const {
> > +    return ".str";
> > +  }
>
> Shouldn't this be called "getUnicodeCFStringSymbolPrefix"?


Perhaps; I think that the distinction probably should go away for regular
strings, but when I first added I didn't want to change our behavior for
regular strings.


> Also, I'm kind of curious, why does this matter?  It's an internal
> symbol, nothing should be able to see it...
>

You'd think! It matters because the name of the internal symbol on Darwin
influences the linker. Symbols prefixed with L have special behavior, which
I don't claim to fully understand...

> +  /// getUnicodeStringSymbolPrefix - Get the default symbol prefix to
> > +  /// use for string literals.
>
> Comment is wrong.
>

Fixed.


> > +  virtual const char *getUnicodeStringSymbolPrefix() const {
> > +    return "__utf16_string_";
> > +  }
>
> Should this be prefixed with \01 for consistency?
>

It could, but I'm not sure it makes the intent clearer. In this case, I just
chose the name to make the IR look more like llvm-gcc; these names are
ignored by the linker.


> > +  if (isUTF16) {
> > +    unsigned Align = getContext().getTypeAlign(getContext().ShortTy)/8;
> > +    GV->setAlignment(Align);
> > +  }
>
> Would it be more natural to make UTF-16 strings arrays of i16's
> instead of manually messing with the alignment?


Currently we match llvm-gcc, which is somewhat of a good thing. Although
that seems reasonable, I don't really know anything about Unicode strings.
For example, I can't even say whether it is correct that we output them in
the host endianness!

 - Daniel
q
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20090402/13d551c9/attachment.html>