| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 293552
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, tstellarAMD
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D28992
llvm-svn: 293476
|
|
|
|
|
|
|
| |
According to the documentation this is supposed to be -1
if indirect calls are not supported.
llvm-svn: 293081
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reason: broke ASAN bots with a global buffer overflow.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/2291
Each test contains 20-30K test cases but takes only several (from 4 to 10)
seconds to complete on average machine. The tests cover the majority of
AMDGPU Gfx7/Gfx8 instructions, including many dark corners, and intended
to quickly find out if something is broken.
llvm-svn: 292974
|
|
|
|
|
|
|
|
|
| |
Each test contains 20-30K test cases but takes only several (from 4 to 10)
seconds to complete on average machine. The tests cover the majority of
AMDGPU Gfx7/Gfx8 instructions, including many dark corners, and intended
to quickly find out if something is broken.
llvm-svn: 292922
|
|
|
|
|
|
|
|
| |
They seem to produce nonsense results when used.
This should be applied to the release branch.
llvm-svn: 292472
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: vpykhtin, artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D28802
llvm-svn: 292224
|
|
|
|
|
|
|
|
|
|
|
|
| |
immediate operands
Reviewers: artem.tamazov, nhaustov, vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D28157
llvm-svn: 291668
|
|
|
|
|
|
|
|
|
|
|
| |
Among other stuff, this allows to use predefined .option.machine_version_major
/minor/stepping symbols in the directive.
Relevant test expanded at once (also file renamed for clarity).
Differential Revision: https://reviews.llvm.org/D28140
llvm-svn: 290710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(.kernel.{v|s}gpr_count)
The feature allows for conditional assembly, filling the entries
of .amd_kernel_code_t etc.
Symbols are defined with value 0 at the beginning of each kernel scope.
After each register usage, the respective symbol is set to:
value = max( value, ( register index + 1 ) )
Thus, at the end of scope the value represents a count of used registers.
Kernel scopes begin at .amdgpu_hsa_kernel directive, end at the
next .amdgpu_hsa_kernel (or EOF, whichever comes first). There is also
dummy scope that lies from the beginning of source file til the
first .amdgpu_hsa_kernel.
Test added.
Differential Revision: https://reviews.llvm.org/D27859
llvm-svn: 290608
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: nhaustov, artem.tamazov, vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D28051
llvm-svn: 290599
|
|
|
|
| |
llvm-svn: 290349
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functime metadata V2.0
Summary:
Added pair of directives .hsa_code_object_metadata/.end_hsa_code_object_metadata.
Between them user can put YAML string that would be directly put to the generated note. E.g.:
'''
.hsa_code_object_metadata
{
amd.MDVersion: [ 2, 0 ]
}
.end_hsa_code_object_metadata
'''
Based on D25046
Reviewers: vpykhtin, nhaustov, yaxunl, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, mgorny, tony-tye
Differential Revision: https://reviews.llvm.org/D27619
llvm-svn: 290097
|
|
|
|
| |
llvm-svn: 289967
|
|
|
|
| |
llvm-svn: 289866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 32-bit instructions with 32-bit input immediate behavior
are used to materialize 16-bit constants in 32-bit registers
for 16-bit instructions, determining the legality based
on the size is incorrect. Change operands to have the size
specified in the type.
Also adds a workaround for a disassembler bug that
produces an immediate MCOperand for an operand that
is supposed to be OPERAND_REGISTER.
The assembler appears to accept out of bounds immediates and
truncates them, but this seems to be an issue for 32-bit
already.
llvm-svn: 289306
|
|
|
|
|
|
| |
Fixes assembler regressions.
llvm-svn: 289230
|
|
|
|
|
|
|
|
| |
compr is not currently parsed (or printed) correctly,
but that should probably be fixed along with
intrinsic changes.
llvm-svn: 288698
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: s_buffer_store_dword instructions sdata operand was called sdst in encoding. This caused disassembler to fail.
Reviewers: tstellarAMD, vpykhtin, artem.tamazov
Subscribers: arsenm, nhaehnle, rampitec
Differential Revision: https://reviews.llvm.org/D27100
llvm-svn: 288657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not in the list of valid inputs for the encoding.
When spilling, copies from exec can be folded directly
into the spill instruction which results in broken
stores.
This only fixes the operand constraints, more codegen
work is required to avoid emitting the invalid
spills.
This sort of breaks the dbg.value test. Because the
register class of the s_load_dwordx2 changes, there
is a copy to SReg_64, and the copy is the operand
of dbg_value. The copy is later dead, and removed
from the dbg_value.
llvm-svn: 288191
|
|
|
|
| |
llvm-svn: 286912
|
|
|
|
|
|
|
|
| |
Test simplified. Coverage extended.
Differential Revision: https://reviews.llvm.org/D26198
llvm-svn: 285844
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes Bug 30808.
Note that passing subtarget information to predicates seems too complicated, so gfx8-specific def smrd_offset_20 introduced.
Old gfx6/7-specific def renamed to smrd_offset_8 for clarity.
Lit tests updated.
Differential Revision: https://reviews.llvm.org/D26085
llvm-svn: 285590
|
|
|
|
|
|
| |
I'm guessing at how it is supposed to be printed
llvm-svn: 285490
|
|
|
|
|
|
|
|
|
|
| |
Also add glc bit to the scalar loads since they exist on VI
and change the caching behavior.
This currently has an assembler bug where the glc bit is incorrectly
accepted on SI/CI which do not have it.
llvm-svn: 285463
|
|
|
|
|
|
|
|
| |
Fixes Bug 28215. Lit tests updated.
Differential Revision: https://reviews.llvm.org/D25837
llvm-svn: 284825
|
|
|
|
|
|
|
|
| |
appropriate relocations
Differential Revision: https://reviews.llvm.org/D25548
llvm-svn: 284195
|
|
|
|
|
|
|
| |
VI added a second method of indexing into VGPRs
besides using v_movrel*
llvm-svn: 284027
|
|
|
|
| |
llvm-svn: 283911
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, kzhuravl
Subscribers: wdng, nhaehnle, yaxunl, llvm-commits, tony-tye
Differential Revision: https://reviews.llvm.org/D25375
llvm-svn: 283593
|
|
|
|
|
|
|
|
|
| |
Partially fixes Bug 28232.
Lit tests added.
Differential Revision: https://reviews.llvm.org/D25367
llvm-svn: 283567
|
|
|
|
|
|
|
|
|
|
|
|
| |
to AMDGPUBaseInfo.h
Reviewers: artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D25084
llvm-svn: 283560
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add AMDGPUSymbolizer for finding names for labels from ELF symbol table.
Initialize MCObjectFileInfo with some default values.
Reviewers: vpykhtin, artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D24802
llvm-svn: 283450
|
|
|
|
|
|
| |
This reverts commit 6c6dbe625263ec9fcf8de0df27263cf147cde550.
llvm-svn: 282396
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add AMDGPUSymbolizer for finding names for labels from ELF symbol table.
Reviewers: vpykhtin, artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D24802
llvm-svn: 282394
|
|
|
|
|
|
|
|
|
| |
Also added range checking for DPP attributes.
Assembler tests added as well.
Differential Revision: https://reviews.llvm.org/D24755
llvm-svn: 282145
|
|
|
|
|
|
|
|
|
| |
Lit tests added.
Resolves https://github.com/RadeonOpenCompute/hcc/issues/122.
Differential Revision: https://reviews.llvm.org/D24765
llvm-svn: 282086
|
|
|
|
| |
llvm-svn: 281967
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In case s_branch instruction target is itself backend should emit offset -1 but instead it emit 0.
'''
label:
s_branch label // should emit [0xff,0xff,0x82,0xbf]
'''
Tom, Matt: why are we adjusting fixup values in applyFixup() method instead of processFixup()? processFixup() is calling adjustFixupValue() but does nothing with its result.
Reviewers: vpykhtin, artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl
Differential Revision: https://reviews.llvm.org/D24671
llvm-svn: 281896
|
|
|
|
|
|
| |
VI added eq/ne for i64, so use them.
llvm-svn: 281800
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23700
llvm-svn: 281081
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also removed duplicate code from AMDGPUTargetAsmStreamer.
This change only change how amd_kernel_code_t is parsed and printed. No variable names are changed.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, wdng, nhaehnle
Differential Revision: https://reviews.llvm.org/D24296
llvm-svn: 281028
|
|
|
|
|
|
| |
Unfortunately this seems to only help the assembler diagnostic.
llvm-svn: 279895
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D22522
llvm-svn: 277344
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D21646
llvm-svn: 276294
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change fix bug 28538
Reviewers: tstellarAMD, vpykhtin
Subscribers: arsenm, kzhuravl
Differential Revision: https://reviews.llvm.org/D22355
llvm-svn: 275422
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue mentioned at:
https://github.com/RadeonOpenCompute/LLVM-AMDGPU-Assembler-Extra/issues/13.
Lit tests added.
Differential Revision: http://reviews.llvm.org/D22133
llvm-svn: 275054
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D22049
llvm-svn: 274852
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D22041
llvm-svn: 274756
|