From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.user Subject: Re: Screaming-Fist: a JIT framework for Guile Date: Wed, 6 Dec 2023 04:30:51 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2250"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Guile User To: Maxime Devos Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Tue Dec 05 21:31:50 2023 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rAc58-0000Pm-0U for guile-user@m.gmane-mx.org; Tue, 05 Dec 2023 21:31:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rAc4T-0004d4-Ac; Tue, 05 Dec 2023 15:31:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rAc4S-0004co-BZ for guile-user@gnu.org; Tue, 05 Dec 2023 15:31:08 -0500 Original-Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rAc4Q-00079K-EM for guile-user@gnu.org; Tue, 05 Dec 2023 15:31:08 -0500 Original-Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-54c64316a22so5474739a12.0 for ; Tue, 05 Dec 2023 12:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701808264; x=1702413064; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XBS/IPZMB1rFIi/fcrWs+j5F3LAO7C+NphxVp8CUy8k=; b=QN10/e4IiZ02tRD9MCBdbrvYXmrdOlEvWhDmZr2H3wIy7sIe0pvRYBYcHLEye1jj5d DnibODdc6eV9PycFeBT1nHmXSId9rEkR8FldB0xydWo9+viF9au3f/DrpqL3mn9LOp9/ 5PGDLZ7KRroYYXNuYuUo4Ei3+rw1bqF44Stbfx34cP72WOiZe4DAGVN+9nRAa+F9ewKu JouPYsYQPcpjcnQySy/woFbc/+YHFS2b4O6lV9LTYrGmoUToDlhOGPTOLtp+GgecofQu IgvqSUQEkcbuxRgzSQ8jLIMTFt+0QcaGfsthOcX86KrpgywpODg7BA4To8rqXx4ESJce 7BLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701808264; x=1702413064; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XBS/IPZMB1rFIi/fcrWs+j5F3LAO7C+NphxVp8CUy8k=; b=nksJTi1yhqxPDbyWIRRKpC5nAslc/wA2BmgfTH0LsBTwXbzQT3G54NLeTccm1I1JGI 9cd86idTuobyptRm/TOzjjgtYHm9szTssEARIqsfjj27KUhmW827VtQ3MbB2jysj3lvq 8x0e7Ehx6b0EhG0W5Af2Jt2x5JIbKY7izMR3mD2YmbSRXYwJA5bWcoJ+RdtzwJpXVSMe nB7l3400w78GITWOrDePo4Vr1i8yMYwfyAx2kjRLiHBg/vl96nc3Vzwns5eHGoKeiBml lA2TbwGF7EAGxxuqex025rTmx00poXZrFqv7lfR4VC4HqbMj8TAwNSs7X47F4EtyHJ05 d/zA== X-Gm-Message-State: AOJu0Yz3bq+04llrKVUCCH88ph5BMWsQUOXZ/o3f2OlF/IGGTSPeacmA eKkwcZv5nhTYgCz+kwKnlfAPYLyASwog2XtC7VQ= X-Google-Smtp-Source: AGHT+IHg+sATqyUmyhIaV1xVD6g3tPAovHccc81kmhdvN/YyfRCNjdvA2eM5P2ffLf4PAvU6ldRlfenklHJ3CL8+UTg= X-Received: by 2002:a17:906:2206:b0:a19:a19a:eab3 with SMTP id s6-20020a170906220600b00a19a19aeab3mr929254ejs.108.1701808264466; Tue, 05 Dec 2023 12:31:04 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=nalaginrut@gmail.com; helo=mail-ed1-x531.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:19357 Archived-At: Hi folks, I confirmed that gcc_jit_context_new_rvalue_from_int is an abstract for various numbers. So the number's validation would be added then. Best regards. On Tue, Dec 5, 2023, 18:14 Nala Ginrut wrote: > Hi Maxime! > > > > On Tue, Dec 5, 2023, 05:26 Maxime Devos wrote: > >> >> >> Op 03-12-2023 om 18:26 schreef Nala Ginrut: >> > (jit-define (square x) >> > (:anno: (int) -> int) >> > (* x x)) >> > (square 5) >> >> >> Potentially-overflowing arithmetic involving ints (not unsigned ints, >> but ints)? Best document somewhere to what the jit code '(* x x)' >> evaluates when (not (<= min-int (* x x) max-int))). >> > > There's no type inference in libgccjit, so the high level framework has to > handle accurate types. > > I use "int" here because libgccjit only provides int rvalue constructor, > yet. It seems lack of rich number types as rvalue in the present > implementation. Even boolean has to be handled by high level framework and > cast it to int respectively. > > May be we need GCC folks help. > > >> Personally, I'm in favor of explicit long names like >> >> */error-on-overflow (<-- maybe on the C-level the function could >> return a tagged union representing (failure [no value]) / (success [some >> value], at a slight performance cost) >> */wrap-around >> */undefined-on-overflow (<-- like in C, for maximal performance and >> dragons). >> > > There was such check, but I've removed it. Since even you detect the > int/short/long exactly, libgccjit only provides int rvalue for all cases of > numbers. I'm not sure if it's waiting for contribution or intended as an > unified int abstract. > > >> (Likewise for +, - and unsigned int) >> >> Sure, they are a bit verbose, but they are explicit and >> non-explicitness+undefined behaviour of'*' in C has caused serious >> issues in the past, so I'd think it's better that the programmer has to >> choose what, in their situation, are the appropriate semantics. >> > > I see your point :-) > Yes, it's a bit hard to provide an abstract arithmetic with type inference > for all cases, providing each for different types will be easier and > flexible. > > Thanks! > Best regards. > > >>