Page MenuHomePhabricator

dpalermo (Dan Palermo)
User

Projects

User does not belong to any projects.

User Details

User Since
Oct 31 2019, 10:17 AM (145 w, 4 d)

Recent Activity

May 13 2022

dpalermo accepted D124759: [flang] Install Fortran_main library.

Thank you @rovka for the original/cleaner approach and @awarzynski for your encouragement to stick with it. Also thank you for your previous patch for adding support to flang-new for generating executables. This makes running new codes through flang-new much easier!

May 13 2022, 7:38 AM · Restricted Project, Unknown Object (Project)

May 12 2022

dpalermo requested changes to D124759: [flang] Install Fortran_main library.

I went back to the original patch, added some more debugging, and found that the options in cmake_parse_arguments had a space instead of a semicolon so ARG_STATIC was never being set.

May 12 2022, 2:58 PM · Restricted Project, Unknown Object (Project)

May 11 2022

dpalermo added a reviewer for D124759: [flang] Install Fortran_main library: awarzynski.
May 11 2022, 7:37 AM · Restricted Project, Unknown Object (Project)
dpalermo accepted D124759: [flang] Install Fortran_main library.

Thanks for the quick response. I've verified that this revision now builds flang successfully for me. I am fine with you committing this. I'll add @awarzynski as a reviewer (since this is related to his https://reviews.llvm.org/rG97a32d3e43fe) in case he has any other suggestions.

May 11 2022, 7:35 AM · Restricted Project, Unknown Object (Project)

May 10 2022

dpalermo added a comment to D124759: [flang] Install Fortran_main library.

If the install logic in add_flang_library is moved into a separate macro (to avoid the "SHARED STATIC"), this problem is avoided and only the archive version of Fortran_main is built/installed:

May 10 2022, 2:14 PM · Restricted Project, Unknown Object (Project)
dpalermo requested changes to D124759: [flang] Install Fortran_main library.

I just tried this patch but it seems to fail when it tries to build a shared libFortran_main.so:

May 10 2022, 2:08 PM · Restricted Project, Unknown Object (Project)

Apr 21 2022

dpalermo edited reviewers for D123828: [mlir][OpenMP] Add omp.cancel and omp.cancellationpoint., added: domada; removed: Dominik_A.
Apr 21 2022, 12:02 PM · Restricted Project, Restricted Project, Unknown Object (Project), Restricted Project
dpalermo added a reviewer for D123828: [mlir][OpenMP] Add omp.cancel and omp.cancellationpoint.: Dominik_A.
Apr 21 2022, 11:58 AM · Restricted Project, Restricted Project, Unknown Object (Project), Restricted Project

Oct 15 2021

dpalermo accepted D111905: [OpenMP][deviceRTLs] Fix wrong return value of `__kmpc_is_spmd_exec_mode`.

I applied this change to see if it fixed the following (since this routine is called when deciding to serialize nested parallel regions):

Oct 15 2021, 3:16 PM · Restricted Project

Sep 9 2021

dpalermo added a comment to D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.

I've reenabled the use of DataLayout::getAllocaAddrSpace as that does indeed still work as intended in the larger runnable test cases that hit this problem...and is the right thing to do since not all target architectures would necessarily have alloca in the local address space.

Sep 9 2021, 5:59 PM · Restricted Project
dpalermo updated the diff for D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.
  • reenable DataLayout::getAllocaAddrSpace
Sep 9 2021, 5:48 PM · Restricted Project
dpalermo added a comment to D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.

Also, as requested, I tried adding --check-prefixes=ALL,AMDGPU and --check-prefixes=ALL,NVPTX to the FileCheck in the test, but that caused lit to report an error that the prefixes weren't found:

Sep 9 2021, 4:18 PM · Restricted Project
dpalermo added a comment to D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.

Potentially interesting that getAllocaAddrSpace returns a different value to local (as that's presumably why they're behaving differently)

Sep 9 2021, 3:42 PM · Restricted Project
dpalermo added a comment to D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.

While updating the lit test as requested (add -mtriple and run for both amdgcn & nvptx), I found that the alloca addrspace(5) and cast to generic was no longer appearing. I backed out the change to use DataLayout::getAllocaAddrSpace...and then the modified lit test started passing. Now investigating what is happening when using DataLayout::getAllocaAddrSpace.

Sep 9 2021, 3:11 PM · Restricted Project
dpalermo updated the diff for D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.
  • update test to pass -mtriple and run for both amdgcn & nvptx
Sep 9 2021, 3:03 PM · Restricted Project
dpalermo updated the diff for D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.
  • ran: git-clang-format HEAD^
Sep 9 2021, 1:05 PM · Restricted Project
dpalermo updated the diff for D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.
  • Updates to code per review (will update test next)
Sep 9 2021, 12:11 PM · Restricted Project
dpalermo commandeered D109500: [openmp] Fix 51647, corrupt bitcode on amdgpu.
Sep 9 2021, 9:06 AM · Restricted Project

Oct 31 2019

dpalermo raised a concern with rL375240: [DFAPacketizer] Fix large compile-time regression for VLIW targets.

This change doesn't appear to be thread-safe. With this change, the Google Halide buildbot (which uses the LLVM HVX backend) detected a crash in a test that was built multi-threaded. When switching the test to build single-threaded, the crash goes away. Backtrace shows the failure is occuring in NfaTranscriber::transition.

Oct 31 2019, 10:29 AM