-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] fuse_ops takes link_params from executor instead of target #10390
Comments
Thanks @kparzysz-quic ! this makes more sense! FoldConstants creates its own PassContext (that explains how the override is ignored) and Target but I do wonder why it needs just take the Executor ? cc: @d-smirnov @Mousius |
In the spirit of creating own config in the FoldConstants, could we just add the expected Executor config too ? tvm/src/relay/transforms/fold_constant.cc Lines 255 to 257 in d9fac4f
|
I think that should work... |
The relevant reproducer is here. #8509 (comment) |
…link-params=0 Addressed issue apache#10390 Change-Id: I1a6b2dd27845f9292f1e07f9da1b9be722481f46
Fix: #10465 |
…link-params=0 Addressed issue apache#10390 Change-Id: I1a6b2dd27845f9292f1e07f9da1b9be722481f46
…link-params=0 Addressed issue apache#10390 Change-Id: I1a6b2dd27845f9292f1e07f9da1b9be722481f46
This fixes the problem. |
…link-params=0 (apache#10465) Addressed issue apache#10390 Change-Id: I1a6b2dd27845f9292f1e07f9da1b9be722481f46
Follow-up to the discussion in PR8509.
Resnet50/float32 model crashes during compilation on Hexagon: changes from the PR enable code execution path that leads to an assertion in function
Array<te::Tensor> ScheduleBuilder::VisitExpr_(const ConstantNode* op)
due to not handling scalar constants of type `float16'. This is a change from the behavior from before this PR.Cause
The
FuseOps
pass gets thelink_params
flag from theExecutor
attribute from theIRModule
, instead of taking it from the current target. If the current target haslink_params=False
, while the executor haslink_params=True
, this will lead to unexpected behavior for the current target.In particular, when compiling a model that uses
float16
constants, havinglink_params=True
inFuseOps
will prevent it from extracting these constants into parameters (which was the original behavior). This will then lead to more relay code being presented withConstantNode
s with typefloat16
, which that code may not yet handle (as is in the case ofScheduleBuilder
).How it happens
Hexagon target sets
link_params=True
, while CPU target haslink_params=False
. During compilation, relay optimizations execute passFoldConstants
. This pass runs relay interpreter with a CPU target, regardless of the original compilation target. During the interpreter execution,FuseOps
pass is executed. At this point the current target is CPU, while theIRModule
'sExecutor
settings correspond to the original "hexagon" target.Edit: clarifications
The text was updated successfully, but these errors were encountered: