[RISCV] Support the large code model. (#70308)

Implement large code model for GlobalAddressSDNode and ExternalSymbolSDNode.

See discussion on
https://github.com/riscv-non-isa/riscv-elf-psabi-doc

[RISCV] Support the large code model. (#70308)

Implement large code model for GlobalAddressSDNode and ExternalSymbolSDNode.

See discussion on
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/388.

---------

Co-authored-by: Kuan-Lin Chen <rufus@andestech.com>

show more ...

[RISCV] Let -data-sections also work on sbss/sdata sections (#87040)

Add an unique suffix to .sbss/.sdata if -fdata-sections.
Without assigning an unique .sbss/.sdata section to each symbols, a
li

[RISCV] Let -data-sections also work on sbss/sdata sections (#87040)

Add an unique suffix to .sbss/.sdata if -fdata-sections.
Without assigning an unique .sbss/.sdata section to each symbols, a
linker may not be able to remove unused part when gc-section since all
used and unused symbols are all mixed in the same .sbss/.sdata section.
I believe this also matches the behavior of gcc.

show more ...

[IR] Don't include Module.h in Analysis.h (NFC) (#97023)

Replace it with a forward declaration instead. Analysis.h is pulled in
by all passes, but not all passes need to access the module.

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

show more ...

[RISCV] Place mergeable small read only data into srodata section (#82214)

Small mergeable read only data was place on the sdata before, but it
also means it lose the mergeable property, which mean

[RISCV] Place mergeable small read only data into srodata section (#82214)

Small mergeable read only data was place on the sdata before, but it
also means it lose the mergeable property, which means lose some code
size optimization opportunity during link time.

show more ...

[llvm] Indirect symbol replacement with GOTPCREL for aarch64 and risc… (#78003)

…v64 ELF

This is similar to https://github.com/llvm/llvm-project/pull/67754 but
adds support for ELF aarch64 and r

[llvm] Indirect symbol replacement with GOTPCREL for aarch64 and risc… (#78003)

…v64 ELF

This is similar to https://github.com/llvm/llvm-project/pull/67754 but
adds support for ELF aarch64 and riscv64 now that GOTPCREL-equivalent
relocations have been added for those archs.

show more ...

[RISCV] RISCVELFTargetObjectFile: use 2-byte alignment for .text if RVC

For the "C" Standard Extension/Zca, D45560 enabled 2-byte alignment for
assembly output (e.g. `clang -S a.c`) and D102052 enab

[RISCV] RISCVELFTargetObjectFile: use 2-byte alignment for .text if RVC

For the "C" Standard Extension/Zca, D45560 enabled 2-byte alignment for
assembly output (e.g. `clang -S a.c`) and D102052 enabled 2-byte alignment for
assembly input and object file output (e.g. `clang -c a.s`).

This patch ports the behavior for code generation and object file output by
adding RISCVELFTargetObjectFile::getTextSectionAlignment (e.g. `clang -c a.c`).

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D150240

show more ...

[RISCV] Replace RISCV -> RISC-V in comments. NFC

To be consistent with RISC-V branding guidelines
https://riscv.org/about/risc-v-branding-guidelines/
Think we should be using RISC-V where possible.

[RISCV] Replace RISCV -> RISC-V in comments. NFC

To be consistent with RISC-V branding guidelines
https://riscv.org/about/risc-v-branding-guidelines/
Think we should be using RISC-V where possible.

More patches will follow.

Reviewed By: asb

Differential Revision: https://reviews.llvm.org/D146449

show more ...

[MC][CodeGen] Define R_RISCV_PLT32 and lower dso_local_equivalent to it

This introduces R_RISCV_PLT32, PC-relative data relocation that takes
the 32-bit relative offset to a function or its PLT entr

[MC][CodeGen] Define R_RISCV_PLT32 and lower dso_local_equivalent to it

This introduces R_RISCV_PLT32, PC-relative data relocation that takes
the 32-bit relative offset to a function or its PLT entry from its
relocation location.

This is needed to support relative vtables on RISCV.

Github PR: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/363

The lld handling of this reloc is D143115.

Differential Revision: https://reviews.llvm.org/D143226

show more ...

ELF: Create unique SHF_GNU_RETAIN sections for llvm.used global objects

If a global object is listed in `@llvm.used`, place it in a unique section with
the `SHF_GNU_RETAIN` flag. The section is a GC

ELF: Create unique SHF_GNU_RETAIN sections for llvm.used global objects

If a global object is listed in `@llvm.used`, place it in a unique section with
the `SHF_GNU_RETAIN` flag. The section is a GC root under `ld --gc-sections`
with LLD>=13 or GNU ld>=2.36.

For front ends which do not expect to see multiple sections of the same name,
consider emitting `@llvm.compiler.used` instead of `@llvm.used`.

SHF_GNU_RETAIN is restricted to ELFOSABI_GNU and ELFOSABI_FREEBSD in
binutils. We don't do the restriction - see the rationale in D95749.

The integrated assembler has supported SHF_GNU_RETAIN since D95730.
GNU as>=2.36 supports section flag 'R'.
We don't need to worry about GNU ld support because older GNU ld just ignores
the unknown SHF_GNU_RETAIN.

With this change, `__attribute__((retain))` functions/variables emitted
by clang will get the SHF_GNU_RETAIN flag.

Differential Revision: https://reviews.llvm.org/D97448

show more ...

[Target] Use Align in TargetLoweringObjectFile::getSectionForConstant.

Differential Revision: https://reviews.llvm.org/D80363

[X86] Reland D71360 Clean up UseInitArray initialization for X86ELFTargetObjectFile

-fuse-init-array is now the CC1 default but TargetLoweringObjectFileELF::UseInitArray still defaults to false.
The

[X86] Reland D71360 Clean up UseInitArray initialization for X86ELFTargetObjectFile

-fuse-init-array is now the CC1 default but TargetLoweringObjectFileELF::UseInitArray still defaults to false.
The following two unknown OS target triples continue using .ctors/.dtors because InitializeELF is not called.

clang -target i386 -c a.c
clang -target x86_64 -c a.c

This cleanup fixes this as a bonus.

X86SpeculativeLoadHardeningPass::tracePredStateThroughCall can call
MCContext::createTempSymbol before TargetLoweringObjectFileELF::Initialize().
We need to call TargetLoweringObjectFileELF::Initialize() ealier.

test/CodeGen/X86/speculative-load-hardening-indirect.ll

Differential Revision: https://reviews.llvm.org/D71360

show more ...

Temporarily Revert "[X86] Reland D71360 Clean up UseInitArray initialization for X86ELFTargetObjectFile"
as it's causing msan failures.

This reverts commit 7899fe9da8d8df6f19ddcbbb877ea124d711c54b.

[X86] Reland D71360 Clean up UseInitArray initialization for X86ELFTargetObjectFile

UseInitArray is now the CC1 default but TargetLoweringObjectFileELF::UseInitArray still defaults to false.
The fol

[X86] Reland D71360 Clean up UseInitArray initialization for X86ELFTargetObjectFile

UseInitArray is now the CC1 default but TargetLoweringObjectFileELF::UseInitArray still defaults to false.
The following two unknown OS target triples continue using .ctors/.dtors because InitializeELF is not called.

clang -target i386 -c a.c
clang -target x86_64 -c a.c

This cleanup fixes this as a bonus.

Differential Revision: https://reviews.llvm.org/D71360

show more ...

Revert "Honor -fuse-init-array when os is not specified on x86"

This reverts commit aa5ee8f244441a8ea103a7e0ed8b6f3e74454516.

This change broke the sanitizer buildbots. See comments at the patchse

Revert "Honor -fuse-init-array when os is not specified on x86"

This reverts commit aa5ee8f244441a8ea103a7e0ed8b6f3e74454516.

This change broke the sanitizer buildbots. See comments at the patchset
(https://reviews.llvm.org/D71360) for more information.

show more ...

Honor -fuse-init-array when os is not specified on x86

Currently -fuse-init-array option is not effective when target triple
does not specify os, on x86,x86_64.
i.e.

// -fuse-init-array is not hon

Honor -fuse-init-array when os is not specified on x86

Currently -fuse-init-array option is not effective when target triple
does not specify os, on x86,x86_64.
i.e.

// -fuse-init-array is not honored.
$ clang -target i386 -fuse-init-array test.c -S

// -fuse-init-array is honored.
$ clang -target i386-linux -fuse-init-array test.c -S

This patch fixes first case.
And does cleanup.

Reviewers: rnk, craig.topper, fhahn, echristo

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D71360

show more ...

[RISCV] Put data smaller than eight bytes to small data section

Because of gp = sdata_start_address + 0x800, gp with signed twelve-bit offset
could covert most of the small data section. Linker rela

[RISCV] Put data smaller than eight bytes to small data section

Because of gp = sdata_start_address + 0x800, gp with signed twelve-bit offset
could covert most of the small data section. Linker relaxation could transfer
the multiple data accessing instructions to a gp base with signed twelve-bit
offset instruction.

Differential Revision: https://reviews.llvm.org/D57493

llvm-svn: 358150

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[RISCV] Use init_array instead of ctors for RISCV target, by default

Summary:
LLVM defaults to the newer .init_array/.fini_array scheme for static
constructors rather than the less desirable .ctors/

[RISCV] Use init_array instead of ctors for RISCV target, by default

Summary:
LLVM defaults to the newer .init_array/.fini_array scheme for static
constructors rather than the less desirable .ctors/.dtors (the UseCtors
flag defaults to false). This wasn't being respected in the RISC-V
backend because it fails to call TargetLoweringObjectFileELF::InitializeELF with the the appropriate
flag for UseInitArray.
This patch fixes this by implementing RISCVELFTargetObjectFile and overriding its Initialize method to call
InitializeELF(TM.Options.UseInitArray).

Reviewers: asb, apazos

Reviewed By: asb

Subscribers: mgorny, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, llvm-commits

Differential Revision: https://reviews.llvm.org/D44750

llvm-svn: 328433

show more ...