Page MenuHomePhabricator
Feed Advanced Search

Fri, Mar 27

t-tye added a comment to D76881: [AMDGPU] Skip CFIInstructions in SIInsertWaitcnts.

Right, but the placement of the meta instructions here can't affect change codegen, can it? Also, if we do need to skip the DEBUG_VALUEs it may also be that we would need to either update or drop them to avoid producing incorrect debug info. I'm not actually certain this is an issue though, but the situation I have in mind is if we pass an argument by-ref or on the stack, and in the callee we claim the value is in memory when the appropriate counts haven't been waited on yet.

Doesn't the placement of CFI matter relative to the real instructions?

Yes, and same for DEBUG_VALUE, which is where my uncertainty comes up. For CFI we absolutely need the directives at the beginning of the block to precede any real instructions, because they apply "on entry". For example, we reference the ABI return address registers here, and we can't have these be defined incorrectly until after the initial s_waitcnt. Conversely for DEBUG_VALUEs it may be that we are constructing them assuming they can reference memory locations for arguments that are only valid after the initial s_waitcnt. So I think we need to handle the two cases distinctly.

ok

Fri, Mar 27, 2:21 PM · debug-info, Restricted Project

Thu, Mar 26

t-tye added inline comments to D76278: [AMDGPU] Don't mark the .note section as ALLOC.
Thu, Mar 26, 9:44 PM · Restricted Project

Sat, Mar 21

t-tye added a reviewer for D76356: [AMDGPU] Introduce more scratch registers in the ABI.: tpr.
Sat, Mar 21, 12:47 PM · Restricted Project
t-tye requested changes to D76356: [AMDGPU] Introduce more scratch registers in the ABI..

Added @mjbedy to review.

Sat, Mar 21, 12:47 PM · Restricted Project
t-tye added a reviewer for D76356: [AMDGPU] Introduce more scratch registers in the ABI.: mjbedy.
Sat, Mar 21, 12:15 PM · Restricted Project
t-tye added inline comments to D76356: [AMDGPU] Introduce more scratch registers in the ABI..
Sat, Mar 21, 11:45 AM · Restricted Project

Fri, Mar 20

t-tye added inline comments to D76356: [AMDGPU] Introduce more scratch registers in the ABI..
Fri, Mar 20, 5:55 PM · Restricted Project
t-tye added inline comments to D76356: [AMDGPU] Introduce more scratch registers in the ABI..
Fri, Mar 20, 11:23 AM · Restricted Project
t-tye added a reviewer for D76356: [AMDGPU] Introduce more scratch registers in the ABI.: b-sumner.
Fri, Mar 20, 11:23 AM · Restricted Project
t-tye added inline comments to D76356: [AMDGPU] Introduce more scratch registers in the ABI..
Fri, Mar 20, 10:49 AM · Restricted Project

Tue, Mar 17

t-tye added a comment to D74995: [AMDGPU] Revert 'Don’t marke the .note section as ALLOC'.

The NOTE section is currently being used to hold the high level runtime metadata, and that is only being read by the language runtimes and so does not need to be part of the loaded code object. So I do not think this note section should ever be marked as ALLOC.

Tue, Mar 17, 3:07 PM · Restricted Project, Restricted Project

Mon, Mar 16

t-tye accepted D76253: [AMDGPU] Print DWARF register numbers in AMDGPUInstPrinter.

Minor suggestion in comment.

Mon, Mar 16, 4:57 PM · Restricted Project

Tue, Mar 10

t-tye added inline comments to D75138: [WIP][AMDGPU] Add Scratch Wave Offset to Scratch Buffer Descriptor in entry functions.
Tue, Mar 10, 8:14 PM · Restricted Project
t-tye added a comment to D75138: [WIP][AMDGPU] Add Scratch Wave Offset to Scratch Buffer Descriptor in entry functions.

I think commit comment "The ABI stack pointer register remains unswizzled, but is now wave-relative instead of dispatch-relative." shuld chage to "The ABI stack pointer register remains unswizzled, but is now wave-relative instead of queue-relative." since for the HSAABI the scratch base is the queue base and not per dispatch. The PALABI may use per dispatch scratch allocation.

Tue, Mar 10, 7:42 PM · Restricted Project
t-tye added a comment to D75913: [AMDGPU] Use progbits type for .AMDGPU.disasm section.

What does the .AMDGPU.disasm setion contain? If it is effectively metadata then using a note record does not seem unreasonable, but that could simply be another note record in the existing note section, and would need to conform to the note record ABI.

Tue, Mar 10, 10:52 AM · Restricted Project

Wed, Mar 4

t-tye added a comment to D75657: [WIP][AMDGPU] Move frame pointer from s34 to s33.

Does the AMDGPUUsage Calling COnvention section also need updating to reflect this change?

Wed, Mar 4, 5:27 PM · Restricted Project

Mar 1 2020

t-tye added a comment to D74688: AMDGPU/GlobalISel: Support llvm.trap and llvm.debugtrap intrinsics.

I believe that the debug_trap trap handler support no longer needs the queue_ptr to be passed in as it is internally computing it from the dootbell ID available from a GETREG together with a doorbell to queue mapping maintained by the ROCm Runtim that is accessible through the TMB register.

So should that change be reflect in this to simplify things? This is does change the ABI so needs the HSA ABI number to be incremented in the ELF header and AMDGOUUsage documentation updated. However, from the compilers point of view it is not ABI breaking as old code will still work, as it is generating code to set the queue_ptr that is unnecessary.

Adding @kzhuravl for ELF ABI version help.

Hi Tony,

If you are specifically asking for llvm.debugtrap() intrinsic here, then, we are already taken care of it, and we are not adding queue_ptr in this case, as you can see from the code changes at AMDGPULegalizerInfo.cpp:3602. The queue_ptr related discussions here are only specific to llvm.trap() intrinsic.

Looking at AMDGPULegalizerInfo.cpp:3602 it appears the queue_ptr is still being set up so not sure what you mean that it is already being taken care of.

The line number has changed with latest changes. I was basically referring to the function - AMDGPULegalizerInfo::legalizeDebugTrapIntrinsic() by assuming that you referring here only debugtrap() inntrinsic.

Mar 1 2020, 10:34 PM · Restricted Project
t-tye added a comment to D74688: AMDGPU/GlobalISel: Support llvm.trap and llvm.debugtrap intrinsics.

I believe that the debug_trap trap handler support no longer needs the queue_ptr to be passed in as it is internally computing it from the dootbell ID available from a GETREG together with a doorbell to queue mapping maintained by the ROCm Runtim that is accessible through the TMB register.

So should that change be reflect in this to simplify things? This is does change the ABI so needs the HSA ABI number to be incremented in the ELF header and AMDGOUUsage documentation updated. However, from the compilers point of view it is not ABI breaking as old code will still work, as it is generating code to set the queue_ptr that is unnecessary.

Adding @kzhuravl for ELF ABI version help.

Hi Tony,

If you are specifically asking for llvm.debugtrap() intrinsic here, then, we are already taken care of it, and we are not adding queue_ptr in this case, as you can see from the code changes at AMDGPULegalizerInfo.cpp:3602. The queue_ptr related discussions here are only specific to llvm.trap() intrinsic.

Mar 1 2020, 8:33 PM · Restricted Project

Feb 27 2020

t-tye committed rGe585a28825dd: AMDGPUUsage DWARF DW_OP_LLVM_call_frame_entry_reg (authored by t-tye).
AMDGPUUsage DWARF DW_OP_LLVM_call_frame_entry_reg
Feb 27 2020, 9:45 AM
t-tye committed rG6e1b97793cfb: Correct typos in DWARF proposal documentation. (authored by t-tye).
Correct typos in DWARF proposal documentation.
Feb 27 2020, 9:39 AM
t-tye committed rG926a2fa6f638: [AMDGPU] Update AMDGPUUsage with DWARF proposal (authored by t-tye).
[AMDGPU] Update AMDGPUUsage with DWARF proposal
Feb 27 2020, 9:34 AM
Gerrit Code Review <gerritcr@atlvgerritapp03.amd.com> committed rG8f6aff52c637: Merge "[AMDGPU] AMDGPUUsage clarify address space information and other typo… (authored by t-tye).
Merge "[AMDGPU] AMDGPUUsage clarify address space information and other typo…
Feb 27 2020, 9:34 AM
t-tye committed rG69bf51b7ea18: [AMDGPU] AMDGPUUsage clarify address space information and other typo and… (authored by t-tye).
[AMDGPU] AMDGPUUsage clarify address space information and other typo and…
Feb 27 2020, 9:34 AM

Feb 23 2020

t-tye added a reviewer for D74688: AMDGPU/GlobalISel: Support llvm.trap and llvm.debugtrap intrinsics: kzhuravl.
Feb 23 2020, 7:10 AM · Restricted Project
t-tye added a comment to D74688: AMDGPU/GlobalISel: Support llvm.trap and llvm.debugtrap intrinsics.

I believe that the debug_trap trap handler support no longer needs the queue_ptr to be passed in as it is internally computing it from the dootbell ID available from a GETREG together with a doorbell to queue mapping maintained by the ROCm Runtim that is accessible through the TMB register.

Feb 23 2020, 7:10 AM · Restricted Project

Feb 19 2020

t-tye committed rG788e74ce29c9: [AMDGPU] AMDGPUUsage define call convention ABI (authored by t-tye).
[AMDGPU] AMDGPUUsage define call convention ABI
Feb 19 2020, 1:02 PM
t-tye closed D74861: [AMDGPU] AMDGPUUsage define call convention ABI.
Feb 19 2020, 1:01 PM · Restricted Project
t-tye created D74861: [AMDGPU] AMDGPUUsage define call convention ABI.
Feb 19 2020, 12:53 PM · Restricted Project
t-tye committed rGf5678d4a6a60: [AMDGPU] Update AMDGPUUsage with DWARF proposal (authored by t-tye).
[AMDGPU] Update AMDGPUUsage with DWARF proposal
Feb 19 2020, 12:43 PM
t-tye closed D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.
Feb 19 2020, 12:42 PM · Restricted Project
t-tye updated the diff for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.

Add DW_OP_LLVM_call_frame_entry_reg and fix typos

Feb 19 2020, 11:00 AM · Restricted Project

Feb 18 2020

t-tye added inline comments to D20556: AMDGPU: Skip waiting on lgkmcnt for global flat loads.
Feb 18 2020, 9:39 AM

Jan 29 2020

t-tye added inline comments to D73651: [OpenCL][CUDA][HIP][SYCL] Add norecurse.
Jan 29 2020, 3:02 PM · Restricted Project

Jan 14 2020

t-tye added a reviewer for D61901: AMDGPU: Assume xnack is enabled by default: b-sumner.
Jan 14 2020, 7:43 AM
t-tye reopened D61901: AMDGPU: Assume xnack is enabled by default.

If this is changing the user visible defaults then the processor table in AMDGPUUsage also needs to be updated and the change of compiler needs to be mentioned in the release notes.

Jan 14 2020, 7:34 AM

Dec 12 2019

t-tye committed rG7a54f727a2a5: [AMDGPU] AMDGPUUsage clarify address space information and other typo and… (authored by t-tye).
[AMDGPU] AMDGPUUsage clarify address space information and other typo and…
Dec 12 2019, 3:55 PM
t-tye closed D71392: [AMDGPU] AMDGPUUsage clarify address space information and other typo and formatting fixes.
Dec 12 2019, 3:55 PM · Restricted Project

Dec 11 2019

t-tye retitled D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal from [AMDGPU] Update AMDGPUUsage with DWARF proposal and other fixes to [AMDGPU] Update AMDGPUUsage with DWARF proposal.
Dec 11 2019, 11:02 PM · Restricted Project
t-tye added a parent revision for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal: D71392: [AMDGPU] AMDGPUUsage clarify address space information and other typo and formatting fixes.
Dec 11 2019, 10:53 PM · Restricted Project
t-tye added a child revision for D71392: [AMDGPU] AMDGPUUsage clarify address space information and other typo and formatting fixes: D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.
Dec 11 2019, 10:53 PM · Restricted Project
t-tye added a comment to D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.

Can you split this up?

Dec 11 2019, 10:53 PM · Restricted Project
t-tye updated the diff for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.

Split non-DWARF changes into D71392.

Dec 11 2019, 10:53 PM · Restricted Project
t-tye updated the summary of D71392: [AMDGPU] AMDGPUUsage clarify address space information and other typo and formatting fixes.
Dec 11 2019, 10:34 PM · Restricted Project
t-tye created D71392: [AMDGPU] AMDGPUUsage clarify address space information and other typo and formatting fixes.
Dec 11 2019, 10:34 PM · Restricted Project

Dec 5 2019

t-tye added a reviewer for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal: zoran.zaric.
Dec 5 2019, 7:42 AM · Restricted Project

Dec 4 2019

t-tye added a comment to D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.

ping

Dec 4 2019, 1:04 PM · Restricted Project

Nov 25 2019

t-tye added a comment to D70424: clang/AMDGPU: Fix default for frame-pointer attribute.

@scott.linder can answer about the -g question, but I would expect that the CFI is capable of describing the address of the CFA regardless of whether there is a frame pointer by simply knowing the constant offset from the stack pointer.

Nov 25 2019, 1:05 PM

Nov 23 2019

t-tye updated the diff for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.

Move note on supporting any integral value to be implcitly converted
to a location description.

Nov 23 2019, 12:33 AM · Restricted Project
t-tye updated the diff for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.

[AMDGPU] Update AMDGPUUsage with DWARF proposal and other fixes

Nov 23 2019, 12:23 AM · Restricted Project

Nov 21 2019

t-tye added a reviewer for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal: arsenm.
Nov 21 2019, 3:06 PM · Restricted Project

Nov 20 2019

t-tye retitled D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal from Update AMDGPUUsage with AMDGPU DWARF proposal and other fixes to [AMDGPU] Update AMDGPUUsage with DWARF proposal and other fixes.
Nov 20 2019, 6:44 PM · Restricted Project
t-tye added reviewers for D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal: scott.linder, b-sumner.
Nov 20 2019, 6:34 PM · Restricted Project
t-tye created D70523: [AMDGPU] Update AMDGPUUsage with DWARF proposal.
Nov 20 2019, 6:25 PM · Restricted Project

Oct 17 2019

t-tye committed rL375198: Request commit access for t-tye.
Request commit access for t-tye
Oct 17 2019, 8:49 PM

Oct 8 2019

t-tye added a comment to D68578: [HIP] Fix device stub name.
In D68578#1700652, @tra wrote:

From a source language point of view, the device function comprises the code that is launched as a grid. We need this fact to be present in the symbols used. Only the device function should have a symbol name matching the mangled name of the device function.

What do you have in mind when you use 'symbol name' here? Is that a symbol as seen by linker? If that's the case, do host and device share this name space on AMD GPUs? In case of CUDA, linker symbols are per-target (i.e. host and each GPU have their own spaces), so they never clash, but the kernel names must have identical mangled name on host and all devices, so the host can refer to the device-side kernel when it needs to launch it.

Oct 8 2019, 7:43 PM · Restricted Project

Oct 7 2019

t-tye added a comment to D68578: [HIP] Fix device stub name.
In D68578#1697898, @tra wrote:
In D68578#1697822, @tra wrote:

Could you elaborate on how exactly current implementation does not work?

I would expect the kernel and the stub to be two distinct entities, as far as debugger is concerned. It does have enough information to track each independently (different address, .stub suffix, perhaps knowledge whether it's device or host code). Without the details, it looks to me that this is something that can and should be dealt with in the debugger. I've asked the same question in D63335 but I don't think I've got a good answer.

HIP debugger is a branch of gdb and the changes to support HIP will be upstreamed. When users set break point on a kernel, they intend to set a break point on the real kernel, not the device stub function. The device stub function is only a compiler generated helper function to help launch the kernel. Therefore it should have a different name so that it does not interfere with the symbol resolution of the real kernel.

I would agree that having distinct names for the device-side kernel and it's host-side stub would probably make things easier for debugger.
However, debugger does have access to mangled names and does see the '.stub' suffix in the mangled name. I don't understand why it can't be considered to disambiguate between the kernel and the stub?
I'm clearly missing something here. Is there a chance to get someone from the debugger team to chime in on this review directly?

Also, I would not agree that they intend to set a break point on the real kernel is the only scenario. E.g. quite often when I debug CUDA stuff, I do only care about host-side things and I do want to set breakpoint on the stub, so I can check kernel call parameters as they are passed to the kernel. It would be great if there were a way to explicitly tell debugger whether we want host-side stub or the kernel without having user to know how particular compiler transforms the name. For the user both entities have the same name, but distinct location and there should be a way to express that in the debugger.

Oct 7 2019, 8:48 PM · Restricted Project
t-tye reopened D45246: Add AMDPAL Code Conventions section to AMD docs.
Oct 7 2019, 8:32 AM · Restricted Project

Jul 24 2019

t-tye added a comment to rL366921: [AMDGPU][MC][GFX10] Enabled GFX10 assembly with arbitrary wavesize assumed by….

How does this work for EXEC mask?

Jul 24 2019, 10:24 AM

Mar 25 2019

t-tye added a comment to D59008: [AMDGPU] Switch default dwarf version to 5.

LGTM

Do we know the state of split DWARF and DWARF compression for DWARF 5 (compared to DWARF 2)?

State of them in what sense? Compression is pretty orthogonal to any DWARF version - it's more about the container (ELF, etc) you use. Split DWARF is non-standardly supported in pre-v5, and I think it's functioning in the standards conformant v5 mode too.

Mar 25 2019, 2:00 PM · Restricted Project
t-tye accepted D59008: [AMDGPU] Switch default dwarf version to 5.

Do we know the state of split DWARF and DWARF compression for DWARF 5 (compared to DWARF 2)?

Mar 25 2019, 11:10 AM · Restricted Project

Mar 7 2019

t-tye accepted D59057: AMDHSA: Code object v3 updates.

LGTM with comment update.

Mar 7 2019, 11:22 AM · Restricted Project
t-tye requested changes to D59057: AMDHSA: Code object v3 updates.
Mar 7 2019, 12:33 AM · Restricted Project

Feb 28 2019

t-tye accepted D58802: [AMDGPU] Mark ds instructions as meybeAtomic.

LGTM

Feb 28 2019, 8:14 PM · Restricted Project

Feb 21 2019

t-tye added a comment to D58518: [HIP] change kernel stub name.

To clarify, I am saying that the stub does have a different name since it is conceptually part of the implementation of doing the call to the device function implementation, and is not in fact the the device function being called itself. However, when we generate code for a function that is present on both the host and device, both copies of the code are for the same source level function and so can have the same symbol name (which was a question that was asked).

Feb 21 2019, 12:11 PM · Restricted Project, Restricted Project
t-tye added a comment to D58518: [HIP] change kernel stub name.

Yes this relates to supporting the debugger.

Feb 21 2019, 11:38 AM · Restricted Project, Restricted Project
t-tye accepted D58159: AMDGPU: Remove debugger related subtarget features.

LGTM

Feb 21 2019, 11:26 AM

Nov 19 2018

t-tye added a comment to D54228: AMDGPU/InsertWaitcnts: Simplify pending events tracking.

Ping?

I think the remarks by @t-tye point to a potentially useful optimization, but that should not be part of this patch.

Nov 19 2018, 8:27 AM

Nov 15 2018

t-tye accepted D53445: [AMDGPU] Update code object metadata format documentation.

LGTM

Nov 15 2018, 12:27 PM

Nov 9 2018

t-tye added a comment to D54228: AMDGPU/InsertWaitcnts: Simplify pending events tracking.

This is sufficient, because whenever only one event of a count type is

pending, its last time point is naturally the upper bound of all time
points of this count type, and when multiple event types are pending,
the count type has gone out of order and an s_waitcnt to 0 is required
to clear any pending event type (and will then clear all pending event
types for that count type).

Just wondered if can do better than using 0. Instead can the lowest count be used as this should be sufficient to ensure all out-of-order events in this have happened? I had discussed this with Bob at one time.

Hmm, how would that work? What lowest count are you referring to? For example, if lgkm has both in-flight SMEM read, and in-flight LDS, we could either have all SMEM read finish first or all LDS finish first.

Something that we could do is a more finely-grained tracking of in-order events. For example, if we have both in-flight SMEM and in-flight LDS, and we need to wait for the second-to-last LDS, then in fact we could do an lgkmcnt(1) wait -- because if the counter reaches 1 or less, the second-to-last LDS must have returned. After the lgkmcnt(1), we still need to conservatively assume that any event type that was previously in-flight may still be in-flight, so this patch here is compatible with such a more finely-grained tracking.

I think the finer-grained tracking could be achieved by introducing separate timelines for each event type: currently we only have timelines by counter. Anyway, it'd be a separate change, mainly for the benefit of mixing LDS and SMEM I think.

Nov 9 2018, 9:25 AM

Nov 7 2018

t-tye accepted D54186: AMDGPU: Enable code object v3 for AMDHSA only.

LGTM

Nov 7 2018, 5:37 PM
t-tye added a comment to D54228: AMDGPU/InsertWaitcnts: Simplify pending events tracking.

This is sufficient, because whenever only one event of a count type is

pending, its last time point is naturally the upper bound of all time
points of this count type, and when multiple event types are pending,
the count type has gone out of order and an s_waitcnt to 0 is required
to clear any pending event type (and will then clear all pending event
types for that count type).

Nov 7 2018, 3:56 PM

Nov 6 2018

t-tye accepted D54178: AMDGPU/Docs: Add product names for Vega20.

LGTM

Nov 6 2018, 2:50 PM

Nov 5 2018

t-tye added a comment to D53153: [OpenCL] Mark kernel functions with default visibility.

But do you want to support *dynamically* linking object files? Because that's what visibility is about.

To be specific, if you don't have multiple levels of linking — doing a slower and relatively more expensive link to form a self-contained unit of code distribution, then doing a faster link to form a runnable program from multiple independently-distributed such units — then visibility isn't really doing anything for you.

Nov 5 2018, 8:16 PM
t-tye accepted D53153: [OpenCL] Mark kernel functions with default visibility.

Summary needs updating as now only being done for kernels and not namespace scope variables.

Nov 5 2018, 1:22 PM
t-tye added a comment to D53445: [AMDGPU] Update code object metadata format documentation.

Should the v2 version of the metadata be moved to a separate section rather than be deleted since it is still generated when the v2 code object format is requested?

Nov 5 2018, 1:05 PM
t-tye accepted D53222: AMDGPU: Add sram-ecc feature.

LGTM (scheduler can be done in separate change list)

Nov 5 2018, 11:20 AM
t-tye added a comment to D53222: AMDGPU: Add sram-ecc feature.

Does the assembler need any support for this? For example, does the .amdgcn_target directive need to accept the +sramecc and ensure the e_flag is set accordingly?

Nov 5 2018, 9:29 AM
t-tye accepted D53223: AMDGPU: Add sram-ecc feature options.

LGTM

Nov 5 2018, 9:17 AM

Oct 23 2018

t-tye accepted D53526: AMDGPU: Switch some lld tests to v2.

LGTM

Oct 23 2018, 4:18 PM
t-tye accepted D53525: AMDGPU: Enable code object v3 by default.

LGTM

Oct 23 2018, 2:32 PM

Oct 22 2018

t-tye added inline comments to D53222: AMDGPU: Add sram-ecc feature.
Oct 22 2018, 1:24 PM

Oct 17 2018

t-tye accepted D53386: AMDGPU: Add options to enable/disable code object v3.

LGTM

Oct 17 2018, 2:27 PM

Oct 16 2018

t-tye added inline comments to D53222: AMDGPU: Add sram-ecc feature.
Oct 16 2018, 9:46 AM

Oct 7 2018

t-tye added a comment to D52891: [AMDGPU] Add -fvisibility-amdgpu-non-kernel-functions.

Another word commonly used across languages is "offload".

Oct 7 2018, 8:41 PM

Jul 20 2018

t-tye accepted D49613: AMDGPU: Switch default dwarf version to 2.

LGTM

Jul 20 2018, 1:29 PM

Jul 17 2018

t-tye added inline comments to D49448: [AMDGPU] Fix VGPR spills where offset doesn't fit in 12 bits.
Jul 17 2018, 5:36 PM

Jul 10 2018

t-tye added inline comments to D49096: AMDGPU: Make hidden argument metadata consistent with amdgpu-implicitarg-num-bytes attribute.
Jul 10 2018, 9:31 AM

Jul 9 2018

t-tye added inline comments to D49096: AMDGPU: Make hidden argument metadata consistent with amdgpu-implicitarg-num-bytes attribute.
Jul 9 2018, 6:41 PM

Jun 21 2018

t-tye added a comment to D48435: AMDGPU: Add patterns for i32/i64 local atomic load/store.

Now this is implemented it may be worth converting the memorylegalizer tests from MIR to IR tests.

Jun 21 2018, 11:45 AM

Jun 14 2018

t-tye committed rL334733: [AMDGPU] Document the AMDGPU LLVM attributes.
[AMDGPU] Document the AMDGPU LLVM attributes
Jun 14 2018, 9:44 AM
t-tye closed D48101: [AMDGPU] Document the AMDGPU LLVM attributes.
Jun 14 2018, 9:44 AM

Jun 13 2018

t-tye abandoned D48103: [AMDGPU] Update code object metadata format documentation.

Abandon as duplicate of D47549.

Jun 13 2018, 6:39 PM
t-tye updated the diff for D47549: [AMDGPU] Update code object metadata format documentation.

Rename note record enmerator from NT_AMD_AMDGPU_* to NT_AMDGPU_* to match the vendor name change from "AMD" to "AMDGPU".

Jun 13 2018, 11:26 AM

Jun 12 2018

t-tye created D48103: [AMDGPU] Update code object metadata format documentation.
Jun 12 2018, 3:48 PM
t-tye created D48101: [AMDGPU] Document the AMDGPU LLVM attributes.
Jun 12 2018, 3:27 PM

Jun 8 2018

t-tye added inline comments to D47900: AMDGPU: Error on LDS global address in functions.
Jun 8 2018, 1:09 AM

Jun 7 2018

t-tye committed rL334257: [AMDGPU] Simplify memory legalizer (add missing virtual descructor).
[AMDGPU] Simplify memory legalizer (add missing virtual descructor)
Jun 7 2018, 6:04 PM
t-tye committed rL334241: [AMDGPU] Simplify memory legalizer.
[AMDGPU] Simplify memory legalizer
Jun 7 2018, 3:33 PM
t-tye closed D47504: [AMDGPU] Simplify memory legalizer.
Jun 7 2018, 3:32 PM
t-tye accepted D47601: AMDGPU: Add 64-bit relative variant kind.

LGTM

Jun 7 2018, 2:53 PM