error: Enzyme: No augmented forward pass found for strcpy

[ax3l]

Hi @ludgerpaehler @wsmoses et al.,

I finally have some time to try to autodifferentiate prototypes for our BLAST codes (GB22 code WarpX, sibling particle accelerator code ImpactX). I started a test and demo case here:
ECP-WarpX/impactx#825

I am writing because I am stuck at an error

error: Enzyme: No augmented forward pass found for strcpy

While the error is sensible, strcpy is not math, I don't get how Enzyme might end up in there. Can you guide me to better ways to debug this or is this an internal bug?
I think this is picked up by a "name" attribute that we carry around with particle accelerator elements, but that attribute does not participate in any math...

The above link has the reproducer using the Clang plugin and a README that contains all instructions. I am attaching the detailed error message here:

error.txt

OS details are Ubuntu 24.02, clang/llvm 16 and the latest development branch of Enzyme.

(In parallel, I'll try to get the LTO+LLDEnzyme plugin to run because more complex examples will later on often need more than one TU. Will report separately on findings.)

[ZuseZ4]

Enzyme/enzyme/Enzyme/ActivityAnalysis.cpp

Line 169 in df197be

const char *KnownInactiveFunctionsStartingWith[] = {

You can probably get Enzyme to recognize it as inactive by adding it to one of the lists in this file. (I am not 100% sure which one is the right one)

[ax3l]

Thanks, I'll try that!

With the LTO plugin, I get a similar error of the form:

ld.lld: error: <unknown>:0:0: in function preprocess__ZN7impactx16evaluate_latticeEd double (double): Enzyme: Cannot deduce type of memset   call void @llvm.memset.p0.i64(ptr noundef nonnull align 8 dereferenceable(40) %50, i8 0, i64 40, i1 false) #96
<analysis>
i64 1: {[-1]:Integer}, intvals: {1,}
  %31 = getelementptr inbounds %"class.std::variant", ptr %8, i64 3, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i64 8: {[-1]:Pointer, [-1,0]:Float@double}, intvals: {}
  %103 = add nuw nsw i64 %101, 1: {[-1]:Integer}, intvals: {1,}
[30 x %"struct.std::__cxx11::basic_string<char>::_Alloc_hider"] [%"struct.std::__cxx11::basic_string<char>::_Alloc_hider" { ptr @_ZNSt8__detail9__variant17__gen_vtable_implINS0_12_Multi_arrayIPFvOZNS0_16_Variant_storageILb0EJN7impactx5EmptyENS4_8ApertureENS4_7BuncherENS4_6CFbendENS4_6ChrAccENS4_8ChrDriftENS4_13ChrPlasmaLensENS4_7ChrQuadENS4_6ConstFENS4_7DipEdgeENS4_5DriftENS4_10ExactDriftENS4_10ExactSbendENS4_6KickerENS4_9LinearMapENS4_6MarkerENS4_9MultipoleENS4_13NonlinearLensENS4_10PlaneXYRotENS4_12ProgrammableENS4_4PRotENS4_4QuadENS4_8RFCavityENS4_5SbendENS4_7ShortRFENS4_12SoftSolenoidENS4_14SoftQuadrupoleENS4_3SolENS4_9TaperedPLENS4_10ThinDipoleEEE8_M_resetEvEUlOT_E_RSt7variantIJS5_S6_S7_S8_S9_SA_SB_SC_SD_SE_SF_SG_SH_SI_SJ_SK_SL_SM_SN_SO_SP_SQ_SR_SS_ST_SU_SV_SW_SX_SY_EEEJEEESt16integer_sequenceImJLm0EEEE14__visit_invokeES13_S16_ },
...

that could point to the same high-level C++ code location... The symbols are differently named though here for the string ops, is there a way to mark those as inactive, too?

Full LDD/LTO error.txt

[ax3l]

Yay, adding "strcpy" in the list of KnownInactiveFunctionsStartingWith works to silence the first part.
Would this be a good PR?

Now I can continue with the next errors (with the Clang plugin).

error: Enzyme: Cannot deduce type of copy   tail call void @llvm.memcpy.p0.p0.i64(ptr noundef nonnull align 8 dereferenceable(40) %24, ptr noundef nonnull align 8 dereferenceable(40) %25, i64 40, i1 false) #55
<analysis>
  %8 = load i8, ptr %7, align 8, !tbaa !13: {[-1]:Integer}, intvals: {}
ptr null: {[-1]:Pointer, [-1,-1]:Anything}, intvals: {0,}
  %40 = getelementptr inbounds %"struct.std::__detail::__variant::_Variant_storage", ptr %5, i64 0, i32 1: {[-1]:Pointer, [-1,0]:Integer}, intvals: {}
[30 x %"struct.std::__detail::__variant::_Multi_array.1025"] [%"struct.std::__detail::__variant::_Multi_array.1025" { ptr @_ZNSt8__detail9__variant17__gen_vtable_implINS0_12_Multi_arrayIPFvOZNS0_16_Variant_storageILb0EJN7impactx5EmptyENS4_8ApertureENS4_7BuncherENS4_6CFbendENS4_6ChrAccENS4_8ChrDriftENS4_13ChrPlasmaLensENS4_7ChrQuadENS4_6ConstFENS4_7DipEdgeENS4_5DriftENS4_10ExactDriftENS4_10ExactSbendENS4_6KickerENS4_9LinearMapENS4_6MarkerENS4_9MultipoleENS4_13NonlinearLensENS4_10PlaneXYRotENS4_12ProgrammableENS4_4PRotENS4_4QuadENS4_8RFCavityENS4_5SbendENS4_7ShortRFENS4_12SoftSolenoidENS4_14SoftQuadrupoleENS4_3SolENS4_9TaperedPLENS4_10ThinDipoleEEE8_M_resetEvEUlOT_E_RSt7variantIJS5_S6_S7_S8_S9_SA_SB_SC_SD_SE_SF_SG_SH_SI_SJ_SK_SL_SM_SN_SO_SP_SQ_SR_SS_ST_SU_SV_SW_SX_SY_EEEJEEESt16integer_sequenceImJLm0EEEE14__visit_invokeES13_S16_ }, %"struct.std::__detail::__variant::_Multi_array.1025" { ptr
...

What does error: Enzyme: Cannot deduce type of copy tail call mean?
error.txt

I can open a separate issue if that would be cleaner.

[ZuseZ4]

I am unable to help with the variant one, as a wild guess I'd say Enzyme should figure that out from TBAA, but I'm not an expert on that. Feel free to make a PR for the strcpy fix, Billy will let you know if it (also) should go into another list.

[ax3l]

Thank you, PR open now in #2236 :)

I played a bit more and tried to get rid of the tail call by compiling with -O1 instead, but the issue persists (now for a regular call):

error: Enzyme: Cannot deduce type of copy   call void @llvm.memcpy.p0.p0.i64(ptr noundef nonnull align 8 dereferenceable(40) %24, ptr noundef nonnull align 8 dereferenceable(40) %25, i64 40, i1 false) #55
<analysis>
ptr null: {[-1]:Pointer, [-1,-1]:Anything}, intvals: {0,}
i64 1: {[-1]:Integer}, intvals: {1,}
[30 x %"struct.std::__detail::__variant::_Multi_array.1025"] [%"struct.std::__detail::__variant::_Multi_array.1025" { ptr @_ZNSt8__detail9__variant17__gen_vtable_implINS0_12_Multi_arrayIPFvOZNS0_16_Variant_storageILb0EJN7impactx5EmptyENS4_8ApertureENS4_7BuncherENS4_6CFbendENS4_6ChrAccENS4_8ChrDriftENS4_13ChrPlasmaLensENS4_7ChrQuadENS4_6ConstFENS4_7DipEdgeENS4_5DriftENS4_10ExactDriftENS4_10ExactSbendENS4_6KickerENS4_9LinearMapENS4_6MarkerENS4_9MultipoleENS4_13NonlinearLensENS4_10PlaneXYRotENS4_12ProgrammableENS4_4PRotENS4_4QuadENS4_8RFCavityENS4_5SbendENS4_7ShortRFENS4_12SoftSolenoidENS4_14SoftQuadrupoleENS4_3SolENS4_9TaperedPLENS4_10ThinDipoleEEE8_M_resetEvEUlOT_E_RSt7variantIJS5_S6_S7_S8_S9_SA_SB_SC_SD_SE_SF_SG_SH_SI_SJ_SK_SL_SM_SN_SO_SP_SQ_SR_SS_ST_SU_SV_SW_SX_SY_EEEJEEESt16integer_sequenceImJLm0EEEE14__visit_invokeES13_S16_ }, %"struct.std::__detail::__variant::_Multi_array.1025" { ptr
...

error.txt

The issue seems around the usage of this std::variant, which stores all possible element types of our particle accelerator beamline.

[ZuseZ4]

Yes, afaik c++ variants are a more rust like version of the classical c style enums. In Rust we don't add any typetree metadata to enums since Enzyme's parser has no way of reading TypeTrees for them. That occasionally results in iaaues like yours. However, C++ has TBAA so enzyme can figure out how to differentiate classical c style enums quite well. My guess was that c++ probably also has TBAA for variants, and that just Enzyme isn't reading them yet.

[ax3l]

Shall I track this as a separate issue? Sounds like this would be a great addition for C++ codes? 🤩

[ax3l]

I'll try to build a reproducer for the std::variant issue and open it separately.
So far, I was not successful in my attempts to make it smaller, all these minimal tests that I wrote pass on Enzyme explorer: https://fwd.gymni.ch/8EXuwJ