areusch commented on a change in pull request #7785: URL: https://github.com/apache/tvm/pull/7785#discussion_r611884529
########## File path: src/runtime/crt/common/aot_backend_api.c ########## @@ -0,0 +1,59 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +// LINT_C_FILE + +#include <assert.h> +#include <inttypes.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <tvm/runtime/c_backend_api.h> +#include <tvm/runtime/crt/error_codes.h> +#include <tvm/runtime/crt/logging.h> +#include <tvm/runtime/crt/platform.h> + +#include "crt_config.h" + +void* TVMBackendAllocWorkspace(int device_type, int device_id, uint64_t nbytes, int dtype_code_hint, Review comment: okay so--sorry, my previous comment was a bit ambiguous. my previous comment is what I want to do in the long-term; for the purposes of this PR, is it possible to avoid introducing `aot_backend_api.c`, particularly since it isn't any different now from `crt_backend_api.c`? to follow-on to my comment and discussion: I don't disagree that we should consider a less memory-intensive lookup mechanism (and thereby changing the implementation of `TVMBackendRegisterSystemLibSymbol` for `runtime.SystemLib`. That brings up the conversation about the firmware-facing API--one I do think we should have--but there are a couple of different things at play there and I think it's something we should tackle separately from this PR. i'd propose in this PR that we should just focus on the TIR top-level function + test strategy and test coverage for that. That does spill over into the runtime a bit--e.g. invoking said top-level function is obviously part of the test strategy. However, I think we should implement something here that suffices to test the AOT as used in the C runtime, and then move on to a conversation about what to do with the `crt/runtime` directory and the firmware-facing API in general. that's the basis on which I'm suggesting to keep with just `crt_backend_api.c` for this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
