llvm dev - Jun 2013 - [LLVMdev] Contants generation - proposal

> I think that the improved behavior for consts should be acceptable in the
large model. But that's just me.
By default, all constants should be in a special read-only section, and this
section may be far from the text section.

I'm working with JIT model or with only one object file. The code model,
when all constants are near, we can call "LargeJIT". (Is it sounds
better then LargeNearConst?)
For X86 target JITDefault will be translated CodeModel::LargeJIT for x64 and
CodeModel::Small for 32-bit.

And the TargetLoweringObjectFile already has CodeModel inside. So the code will
look like :

const MCSection *
TargetLoweringObjectFile::getSectionForConstant(SectionKind Kind) const {
  if (getCodeModel() == CodeModel::LargeJIT)
    return TextSection;
  if (Kind.isReadOnly() && ReadOnlySection != 0)
    return ReadOnlySection;

  return DataSection;
}

-  Elena


-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: Tuesday, June 25, 2013 23:31
To: Demikhovsky, Elena
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Contants generation - proposal

Hi Elena,
> (2) Proposal
> Define one more Code Model, let's say "LargeNearConst", which
will allow to put constants in .text.
Isn't that a little heavy-handed? The large model only requires the less
efficient access for symbols we can't control, and in fact x86 still uses
pc-relative conditional branches within a function so it can't pretend to
support a single function >2GB in code size even now.

I think that the improved behaviour for consts should be acceptable in the large
model. But that's just me.
> I'd like to hear people's opinion. Will it help other targets?
I'm ready to send a patch.
An analogous improvement would be useful for AArch64, which means that if the
new model *is* justified it would probably be useful there too.

Cheers.

Tim.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

>> I think that the improved behavior for consts should be acceptable in
the large model. But that's just me.
> By default, all constants should be in a special read-only section, and
this section may be far from the text section.
Why should they? The only reason I can think of is to support
execute-only pages, but isn't that the less common use-case? From what
I could tell from a quick search (very non-thorough), none of the
mainstream x86 operating systems enable it by default.

Cheers.

Tim.

All compilers do this, gcc, for example
#include <stdio.h>

const char A[] = {"Hello, world"};

int main() {
  printf("%s\n", A);
  return 0;
}

gcc hello.c -o hello

objdump --all hello | grep -w A
00000000004005d8 g     O .rodata        000000000000000d              A

-  Elena


-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: Wednesday, June 26, 2013 14:23
To: Demikhovsky, Elena
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Contants generation - proposal
>> I think that the improved behavior for consts should be acceptable in
the large model. But that's just me.
> By default, all constants should be in a special read-only section, and
this section may be far from the text section.
Why should they? The only reason I can think of is to support execute-only
pages, but isn't that the less common use-case? From what I could tell from
a quick search (very non-thorough), none of the mainstream x86 operating systems
enable it by default.

Cheers.

Tim.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.